The ins-and-outs of thevocket.com – Part 1
TheVocket – a collaboration project with a friend of mine, Mohd Fazreen Jasni since early July 2014. The 6-months-old side project gave me an opportunity and a stage to play with huge crowds, and they are an avid readers.
Monthly Pageviews : 5,200,000 views Daily Pageviews : 100k - 200k views Peak Traffic : 2000+ live readers Normal Traffic : 300 - 500 live readers
It was a fun and knowledgable journey.
Then, few of my friends and some of the readers who were curious about thevocket.com, asked about its server configuration and the system behind it. So, lets dig into it and apologise if the remaining story went going too technical.
This project is based on WordPress CMS as its publishing platform because it is free, relatively easy learning curve, and has wide support on the internet. Very wide.
For the WordPress setup, i tried my best to minimize utilisation the usage of plugins. If a feature can be coded natively into the theme, then do not use plugin. Sometimes, what we want to implement in the theme was very minor, or static and this can be hard-coded into the theme itself.
The most important plugin for this project was W3 Total Cache as one of the mechanism for caching. It helped with page caching and also database caching (memcached). 'Page Caching' is a concept to store fully rendered HTML files, which were processed through PHP.
Referring to the attached image at the top of the post, 'User Request' is the reader. When someone typed thevocket.com in their browser, it will send a 'request' to our server. And the server that will be accepting the request is server A, because this is the first door to the other server, the most frontal server.
Server A is meant to store all the informations which have been fully processed, and this is also called 'caching'. The idea of having this server is to serve as a huge 'Library'. There will be no data processing at all.
However, if the requested page was not found on Server A, the request will be forwarded to Server B.
Server B, which use LEMP configuration (Linux Nginx MySQL PHP). Nginx is pronounce as 'Engine X'. Because Nginx is just an HTTP server, the request will be proxied to PHP for processing, in case you forgot that WordPress is based on PHP.
At this level, common and used PHP codes will be cache by OPcache for future reuseability. Then, through W3TC plugin, the requested page will be rendered as HTML file, ready to be sent to the browser.
When the page went through Server A, it will be cached again to serve for the same request by next reader without having to go all the way to Server B
The attached diagram is specially done for thevocket.com, a blog. This setup only focused on reading performance. For a server with inputs from user, the data processing power is very crucial, and most of the time it involved a lot of RAM and PROCESSOR power (cores?).
If we look closely, thevocket.com is not using any CDN services, because most of the CDN focused on the outside of Malaysia, while our readers came from inside Malaysia. Furthermore, CDN services such as MaxCDN is still beyond our budget and the quality of Cloudflare seems to disappoint us.
We decided not to use CDN and just a common cache server at the moment, which is Server A (with Varnish Cache).
There are many more configurations that can be done with all the technology available. Standalone server, multiple backend, Master-Slave, multiple front-caching (DNS configured), vertical-horizontal setup or event Standalone-Backup settings.
Feel free to comment for Q/A.