 So, I'll be talking about things that maybe in specifics there's going to be people that know better the details. But one thing I have the privilege of having is an open view on what happens when a large company embraces WordPress and the aspects that overall impact the business. So about me, I was already introduced so I can actually skip it. One thing is that my colleagues say I'm actually a fusion of a marketer of an IT because I have a past experience as an IT and also as a designer because that's the job I do usually on Fridays because we still don't have a designer in my company and I have to design my own stuff. So, in November 2016, I was asked to start working on this project, the launch of a low-cost mobile operator and they gave us one month time to go live, which wasn't much. And so we just chose to speed start on a series of things. So first thing, use what you know. We had competence on the LAMP stack, so something based on PHP WordPress and WooCommerce on top of it. And a classic operator's website is made by a homepage where you show your products, showcase the e-commerce where you purchase it and recharge the credit because especially here in Delhi, it's typical to have rechargeable sims. In the customer area where you manage your subscription. So we adopted this approach. First do it because we had very little time and then do it better, which is actually a quote from Osmani from Google. And so why WordPress? Well, first of all, we had a very low budget and it's free. It was quick to deploy, PHP-based, we had competence to handle it. We bought a professional template and speed started thanks to that, which is a really good choice in the short term, really bad choice in the long term. Of course we needed a CMS because they had people doing different jobs, so you have to have a distributed way of updating content. And WordPress is proven. I was using WordPress for more than 10 years, so I knew it pretty well. And so we were confident we could do the job on this platform. So in the digital life cycle, we adopted some tools and maybe this is useful too to see. Like when we develop and we keep our repository on an instance of GitLab. To do our tests, we have automated most of our tests in Catalon Studio, which is a free product we're using to do testing, automated testing. And we also use the Catalon plugin, which allows you to record interactions on the website and export them even in Python. So we have scripts that run and test the functionality of the website to warn us if things goes wrong. To deploy and measure things, we have as a monitoring tool, for example, we use Pingdom, we use of course Google Analytics because that's very useful. We use Kibana to analyze logs and do end-to-end monitoring of our processes. So if you buy a sim on the website until it is delivered, we have all the system it crosses and see if there's a problem of something in the middle that breaks and it's not working. We're starting to work on Kubernetes. We haven't employed it yet. We would really like to. And for design, well, we use various tools, but as I told you, we started on Avada as a template. So for monitoring, well, first of all, we can monitor website performances through the reports of our CDN provider. A large company like ours needs a CDN. This is one of the things you can't do without. And this is very useful because you can see the traffic on the outside and you can see what are the hits on internally. A CDN offloads more or less 80% of your traffic. So that means you have to handle a smaller amount of traffic and it also protects you from attacks. We monitor our API calls. This is a screenshot from Kibana. So these are our APIs, numbers of requests, numbers of failed requests. We can check if the failed requests grow high. Mainly they're just because people inputted wrong data, like they try to recharge a number which is not valid, which happens. But still the API gives an error and we monitor it. Of course, we monitor the uptime. And you also have to monitor page speed. Page speed, page weight is very, very important. It determines experience, but it also determines the load you have on the CDN, which you pay for bandwidth. So that's money. And also on the load you get on your servers. So it's very important to do some house cleaning every now and then keep sizes as small as possible. Plus you have to monitor all the rest. So as I was telling you, we monitor purchases, recharges of the SIM, customer area activities. We do quite a lot of monitoring in our customer area because also in the purchase process, because if you see there's phases in which the customer is slow, you can actually optimize the experience and improve it. Of course, we also have a series of scripts that do monitoring of coherence of the information our REST API respond. For example, we have a REST API for our app. And since there's information like the number of minutes of an offer and things like that, we check that it's coherent because it could be the editor who has entered that product, has made a mistake and has put the wrong number of minutes on it. And so you see different minutes on the app with respect to the site. Of course, we use Google Search Console to optimize our SEO presence. And we send alerts a lot. We use Slack. We have webhooks for practically all the monitoring stuff that ends up in a dedicated Slack account. Sometimes email, sometimes telegram reviews, also telegram for some of the things. So the web architecture, just to summarize, in our case, we have a CDN provider and it's Akamai. We have, of course, a firewall. We have a load balancer cluster, which in this case is F5. And currently, we have 12 front ends. Depends on your context. In our case, it matched in the blades that were underneath. So we have all the front ends on different blades. And we have a dedicated server where we use the PHP admin so you don't see it from the outside. It's just one of the parallel instances, but we from the inside can access the PHP to the administration functions. And otherwise, from the outside, you don't. MySQL cluster, we have two read-only and one read-write. And behind that, for authentication, we use LDAP and all our API services. For the app, we have a dedicated infrastructure. We started out that we were sharing infrastructure with web and app. But the numbers of app went really high. And so it was creating problems. So we decided to divide. Divide and conquer is always a good philosophy. So if you divide things, you have less interactions, and you can manage things better. The app uses REST API to acquire content to. You can also purchase services through the app through REST API. So this is the part I hope you're most interested in. What are the lessons we learned? Because in two years, you learn a few lessons. So first of all, you have to offload. Offload all you can. And so it's important to have a CDN. And it's important to have a cache plugin. Those are two things you have to have. Otherwise, if you just put a plain WordPress instance online, even if you have 12 servers, and it just will crash as soon as you have 400 concurrent sessions, it will suffer a lot. If you have a cache, you have less requests to the MySQL database. And so performance go way up. The CDN, as I was telling you before, offloads more or less 80% of the traffic. So that's also very important. And the CDN has also a great impact on user experience. Because we've used different CDNs. Currently, we're using Akamai. And the great thing about Akamai is that they have a lot of servers distributed across geographically. They have servers in all the web farms of mobile operators, ISPs, and so on. So the perceived performance of the website is really good because you have your server right there. And the other thing they also do is they deliver an HTTP2. So on mobile, it's also very, very fast. After you offload, you have to distribute the remaining load. So you have more front-end servers. And you can choose to have a few very powerful servers or many less powerful. It depends on the infrastructure you have already. We decided to distribute them on more servers because we had more blades. So they're not physically on the same hardware. And then, of course, you have to have a hardware load balancer to distribute traffic well across those servers. And the MySQL cluster is useful. And HyperDB is very, very good to access tables on the read-only instances and on the read-write. So you actually distribute the load of the MySQL cluster also. I think also WordPress uses HyperDB for their main website. And I think it's a really good product. So maintenance, you must consider your database like a garden. So you have to keep it clean because it tends to fill in with stuff. We have just monitoring of how tables grow. And strange things happen. You update a plug-in and a table just goes bonkers. It grows really quick. So you don't have to let it overgrow. So we did a few things. Like since WooCommerce puts all your purchases inside the WhoopiPosts table, WhoopiPosts meta, and so on, we have a process which acquires the order and deletes it. So we don't keep our orders on the WordPress instance. They're imported on a different platform. So that allows us to have WhoopiPosts and WhoopiPosts meta's really small tables, and they're much more performant. And in the beginning, we didn't do that. And the performance is just going always slower every day because you can maybe acquire maybe 500, 1,000 customers a day. And PostMeta has many records for each order, and that's a lot of stuff. So they grow really quick. You have to be very careful with plug-ins. Before using them, you have to also stress test them and see the performance. You have to also verify their impact on DB. Like we're using Yoast, and it was creating a lot of records on the database for each order, which actually don't need to be optimized for SEO because it would consider it as any other content. And so it was creating the records to optimize SEO of the orders, but of course, it's not important. So well, our choice was to keep the orders away from the platform directly, so that solved the problem beforehand. Keep things updated. So you have to update your software stack. And it's a high priority when it's a benefit. Last year, I was here, and I listened to a few talks. I heard about the performance of PHP 7.2. And we tested it in our labs. And that was four times more performance with the previous versions we had. And so four times is a lot. That means you have four times the hardware capability you had before. And of course, you have to update WordPress and plug-ins. And also, there's always space to improve for improvement. So everything, a single thing, can be improved. So CDN, what we always do is take a look at the stats and find out if there's any pages which are have offload percentages. And we work with a provider to have it cached more aggressively, because in many cases, it can be cached. And it helps. It keeps that 80%. Maybe you can bring it to 85 or something. It's always less stuff. Web server, we've evaluated working on Nginx on Apache. We've also tried using Nginx as a reverse proxy. Currently, we're using directly Apache because it actually is less complicated for a series of technical issues. And since the rest of the infrastructure is handling traffic so well, we don't have this urgency. But in case we need, we could move to Nginx, which is quicker, but less versatile than Apache. As far as the database, we're using MySQL. But we could consider also moving to MariaDB. It's more performance. In our case, it's not good. But maybe in other contexts, it can help. Of course, PHP, as I told you, 7.2 was a big improvement. And also, one could try using HHVM, which is developed by Facebook. In our case, we tried it. It didn't actually improve performance as too much. It was more or less the same as PHP 7.2. So we stuck with 7.2. Software, as I was telling you, you can also improve maybe if you find a caching plugin that works better, that can help. It's better than the one you're using now. Because sometimes caching plugins have a few problems, and you have to be careful with them. You also have to be very, very careful with the configuration. Like one time, a colleague of mine changed an option in the store locator. And all the platform crashed completely because it changed the approach. Currently, the store locator searches after you enter the page because it asked you to get localized. And then it searches. It was searching beforehand. So as soon as you went to the page, it searched once. And then it searched the second time after you localized you. So it was doubling the number of searches. And the first time, it didn't know exactly where you were. So it actually put us in a difficult situation. And it took us some time to find out what was going wrong. Also, one thing we have to do, we haven't done it yet, is to build a custom high performance theme. Because commercial themes are actually as light as you could want. And you need to do one. And we can't an embracing Gutenberg as soon as it's more mature. We've been trying it a bit. We need a few more features in it. And I think they're really coming into Gutenberg. So I think it is the correct approach. So from my favorite book, So Long and Sang, thanks for WordPress. And so if you have any questions, feel free to ask questions. No, you're all hungry, yeah? OK, any questions? Let's eat. Oh, it's the same? You've never translated it in English? Yes. Wait, wait, wait. So, a little technical question. The choice of WordPress has been made exclusively by your team. Did you have to face other business structures or were you completely autonomous in choosing it? I'll ask you this question. I'll explain why. I also work in a large structure, in particular a public mind. I work as a consultant. I found myself offering WordPress for a whole series of reasons, objectively valid, et cetera, et cetera. And sometimes there have been resistances in environments, let's say, not technical, for the fact that WordPress is a tool for everyone. If it's for everyone, it means it's not as good as tools that are very difficult to use, and therefore are better. My question was only this. So, first of all, I'll answer in Italian, then maybe I'll do it in English. The choice of WordPress has really been mine, in the sense that our IT team was very happy to have one of the marketing companies that decided to use that platform so that it would limit its hit. Because, let's say, it never disappointed us to be able to hit someone else. We are a very, very small company, so marketing takes a lot of stuff, I don't know, GDPR, I've done it on my own, that is, being few, you have to do a lot of things, you have to have a lot of hair. So he was asking if the choice of WordPress was, who took the choice to use WordPress? And because in some companies, not many companies are willing to choose WordPress because it's maybe considered too basic of a platform. And so it was my choice at the time, and our IT team was very happy to have marketing take a choice for the platform, so it would be my fault, and not theirs. Okay, I guess we're going to lunch then. Thank you, everyone. Thank you.