 So basically this is basically a show and tell session so basically how two of our skills, technician, infrastructure, okay so something i'll start about me i've been a work-press plugin developer for most my 12 years so i developed some of some of plug-ins like page navi pose so you can check it out so currently i'm working in technician as a tech guy so basically doing all work-press related together with Robert Robert is just join us like two weeks ago i think yeah so we are still hiring if you are looking for a job or work-press related job yeah so i'll start so if you may not know Willis so Willis is basically the CEO of tech in Asia so he approached me to join tech in Asia and I spent an engineering team that was roughly in July so i was still with Mick 33 back then which is also Michael also was my ex-colleg as well then after that in August we hire an awesome engineer Lee Chun so basically both of us started work to scale tech in Asia so previously there's a developer right now there's only one developer in tech in Asia so when we took over is basically two of us so previously we are on digital ocean running on one server the server will probably crash when you reach like 500 users so we are paying like 320 a month for it which is very expensive then when we took over we basically moved it to soft layer because it's free they give us 10,000 credits for if you have start up can properly apply the start catalyst program they offer you 10,000 credits a month yeah so right now tech in Asia is running on per three four five six seven seven servers one load balancer because the catalyst is basically a year program they are they basically give us they extended to next year so after next year we told them we probably move out most likely to AWS definitely so when Chris mention whatever structure is what we already did plan but the elastic force system is not out yet so we can't really do any testing hopefully it'll be out soon yeah it's in preview now yeah hold it up for public soon yeah so yeah that will be moving to AWS eventually anyway yeah so once we move all the server to soft layer the first thing that we should do is basically monitor the server if you don't monitor server there's no way to measure your performance whether it's any improvement whether the server is not performing or something like that so we are using graphite to monitor all our all our server stats so graphana is basically just a front end for graphite and graphite collects data from collectee which is basically a daemon and this daemon basically collects all the information like memory RAM and push to graphite we can see it just nice so whenever you push something out you will know whether it's performing based on a chart if there's a spike something must be wrong so we will normally take a look at it and fix it on the fly so one of the key features that Chris mention is WordPress when you have multiple servers one of the common problem is how do you handle user uploader files we got about 10 years worth of images in our servers so basically we tried using an NAS at first but it was just very painfully slow so that was before Amazon has elastic file system so we that luckily one of the common solution is Glastafs so basically it syncs you can you can define mall points and he can syncs that particular mall point across all servers it happens almost instantly so so far we have been using for one year is it's pretty it's pretty good so if you are running your own servers and needs to have multiple web servers you can take a look at Glastafs so we also did some changes to how WordPress works as well so we firstly remove WordPress used to be in a root folder so we basically move further WordPress to a folder on its own which is called a folder called core there are two things to this is basically is a it to prevent automated automated attacks based on the URLs and also we is a git checkout of WordPress in GitHub so when anybody has unauthorized modification to WordPress itself we will know you can run a cron job that monitors the directory like git status and send you email everyday if there's changes because if you have all your files in the root folder without a git checkout you will not know what file has been modified by the hackers the other one we did was we hasty press the whole site just so that increase sensitivity and equation and give a slightly ranking boost in Google yeah okay so WordPress was using 83 plug-ins when i was there so we clean it we remove 48 plug-ins and we cut down to 35 plug-ins so some of the plug-ins are very very very polycoded so when you delete a plug-in some plug-ins doesn't have an uninstall.php to remove the data that have get created living behind a lot of junk data so data like plug-in options some they added some post meta to your post comment meta user meta so once we fix all that it took us about a week to fix all that so literally going through the code starting the code find what options it create and delete manually from the database so this will be a huge improvement boost see when we wrote roll a code up we can see immediately our database traffic size spike drop by half which makes it's more efficient so that's why i say it's important to monitor your server so that you will roughly know what benefits you'll get in return so of course we are previously we are using edge cast which is really horrible it's horrible expensive and doesn't provide a free SSL set since we SSL our own site with our CDN is we have SSL set as well and it charge like what $700 just to have an SSL option us a month so we decided screw it and we go with max CDN again it's free for us we like to bootstrap so whatever free we just take so we are stagnation was part of YC we got a max CDN deal is literally free for us so the next once we solve the server we solve the plug-ins now next is the team okay the team was also very despondely very polycoded stem by some development studios there's no proper use of WordPress API so there's like unnecessary SQL queries over the place that's like no central point you want debug you basically have to go to all the codes and find where calling and the CSS and JS is not minify of combined and one thing I don't like is the features they comment out the HTML portion of it by using the HTML comments but they leave the PHP and SQL code inside so even the feature is not displayed it's still being loaded yeah so we we design the team from scratch literally just delete away the folder we remove we talk with the stakeholders like editorial team our product team we remove unnecessary or unused features we flatten the whole UI using SVGs and for not for my cons so of course yes we minify it and combine it and of course caching so as long as the information will not change we normally cash for an hour by default and then cash now this set this is still the old layout that we have so our previous web stack was basically Apache PHP and my SQL the standard just our hobby I just upgraded it to engine XHVM and using MayaDB for engine X and HHVM we notice quite a lot of difference in terms of speed and does of page rendering it literally cut form almost a second to about 0.1 second using HHVM and engine X for MayaDB and MySQL personally I don't really find any much performance improvement in fact MayaDB crashes a few times on a few tables and yeah so yeah I'm done already yeah just keep it short so yeah so basically this is summary what we did when I took over move the servers clean up plugin redesign team and change our web stack yeah so for future plans we have basically plans to as I mentioned earlier to move to AWS to make it dockerize everything I'm still learning docker yeah so make it everything yep yeah yeah HHVM basically it's keep up kumpup code we use we now use HHVM we still a compare we still a switch it to HHVM from the Apache mod PHP module we skip the FEM part yes so we are there's also I'm taking along a way lah I mean performance is an ongoing process so we tweak the memory the just in time size and stuff then we will use if you let me see we haven't do such such she still basically using Google custom search we have plans to do such probably it's in a product line but not so soon we are we still exploring so normally how I compare can you see okay so normally how I compare is basically we have this and using this plug-in call query monitor so basically as you can see on the index page with our new layout by the way so you can see that there's you only uses like 6 MB and 0.1 second so before when I before I switch to HHVM we're getting about like 0.8 0.9 1 second just to render the whole page so HHVM literary cut cut it down to 0.1 I think it's the page rendering size setting it's the it's the page rendering size that including all the database and everything they got the database they will break down everything so we see it's everything all in one because we upgrade all your ones so we can't ready be sure but as far as I know MayaDB has not much info pun lah that's a plug-in call query monitor query monitor yeah yeah this one correct you give that information you break down any PHP error any Ajax error it's awesome yeah I totally recommend that even on the production side it's good to use it yes yes you log in but you also can measure lockout they allow you to create a cookie so you can click a button create a cookie so you can see the lockout performance as well yeah so you know whether some of queries are caching and some are not correct you can see the offline version of it yeah query monitor yeah I like it I see it's like almost 5 star out of 5 92 developers I'm pretty sure yeah okay I'm done anymore question okay shameless plug I got my own plug-in which I basically wrote for tech in Asia actually so I make it open so it's called WP sweep it cleans up all this information not sure you can see it cleans up maximise it so this is all the things that it cleans up revision auto draft deleted commands unapproved commands spam commands all this you will clean it up that's one thing I wrote when I did the clean up and I decided open source it yeah we basically make changes to the code and we just check out normally we and we have for example there's if there's a new database we normally created before we deploy the code so for content changes we don't really do much content changes or we do content changes on staging then after that we just deploy the code production issue work there's another plug-in called RAM but I'm not too sure whether how it works it does what you mentioned it's called RAM WordPress let me see yes it's this one it basically does yes we don't do any changes yes so there's this and nothing called RAM which is basically does content deployment from staging all the way to production if I'm not wrong yeah it sings your yeah I guess it's a plug-in I think it's a paid plug-in for this yeah it's 249 yeah so basically it puts to staging it test and it will sings to production I think that's how roughly it was didn't wait test it but it's a quite a popular plug-in yeah yeah it's alright yeah it's okay unless there's yeah it's okay no we basically run the queries on staging first then we run the exact same query on production yeah yeah both of course yeah before we deploy the code no no easy I basically write a script to find all the option and compare it so for the option I think we clear from 6,000 rows 292 yeah that's why you see that the despite in the queries yeah it took so long time yeah correct because wordpress as a for options as a autoload column which basically set to years by default so if let's say you use a lot options it will just yeah it's part of your payload in every page but I can't see there's any solution for it because unless there's like a central repository like this plug-in users this option name then you can check against a central database but if every plug-in users is own option name there's no way to determine whether or not it's being used bila tak cek kode yeah yeah but some options are because we still have some plug-ins existing plug-ins so some of them might be still using the options and they are own plug-in options so since we remove 48 plug-ins we have to check the code of this 48 plug-ins to see what options they left behind yeah so it's a very tears manual job yeah unfortunately there's no automated way I can find yeah it will not remove the it will not remove the options so basically I when I remove the plug-in I will just see what he have a normally has a ad update or ad options I'll find a key name and I just did it directly from the options of course I wrote a script to do it ah yeah I wrote a script to do it so it's much faster but of course I wrote it's still some human checking involved cannot be automated yeah okay thank you