Here is another short review on how an OpenVZ-based VPS running VestaCP with Nginx and Php-fpm stack can perform in a real production environment hosting real website with real traffic. Previously, I also posted another short review about VestaCP performance using its default configuration (Nginx as frontend proxy, Apache as webserver, PHP, and MySQL). The result was pretty impressive which until then the server received traffic spike. The server was basically ok but I had to move it to another server due to a number of reasons which I can not describe them here. Instead of just moving the website to new server, I wanted to also try different configuration. Hence, I decided to install VestaCP with pure Nginx as webserver and PHP-fpm. Moreover, I always wanted to try Redis so I also installed it alongside with Vestacp.
- Server : VPS (Virtual Private Server)
- Virtualization : OpenVZ
- OS : Ubuntu 15.10 Minimal 64-bit
- RAM : 1GB (512MB VSWAP)
- CPU Model : Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GH
- CPU Cores : 4x 3400 MHz
- Provider : RamNode
- Control Panel : VestaCP
- Configuration : Nginx + PHP-fpm + MySQL + Redis cache
- Website CMS / Platform : WordPress
- Caching plugins : Redis Object Cache and Cache Enabler
- Content Delivery Network : KeyCDN
Do you want to setup the same server as what I used above? Just read and follow my previous tutorials:
The Traffic Stats
Again, I use the same website as what I used in my previous review. The only difference here is the increasing number of its visitors.
p.s: You may wondering why the date in the screenshot pic is last month. Well, basically I had prepared the materials of this post last month once I successfully and was happy with my new setup. However, I don’t want to post it before I have posted the tutorials on how to have the same server setup. Hence, here it is the review.
p.p.s: The website having that traffic was sold 2 weeks ago. It was my husband’s website actually. Therefore I have no newest version of its traffic stats.
Traffic stats per day:
At that time, the website received traffic about 23k – 26k unique visitors per day with 48k – 61k page views per day.
How can the VPS hosting that website survive handling such traffic? Now let’s take a look at the stats of the server:
Below is the screenshot of the server performance stats as recorded by Nodequery. However, Nodequery fetches data every 180 seconds and therefore I had to wait for Nodequery to fetch new data (refresh the stats) and then I took a look at the traffic stats at HiStats.
The server stats above was taken when the website had 360 users online at the same time which was not the highest number. Usually, the website had as high as 390+ online users that happened few times in a day. The lowest number of online users was 180+.
It can be clearly seen from the screenshot pic above that the average system load of the server having 360 online users was ONLY 31% (1.05 1.24 1.25). That system load is obviously lower than the one taken from my previous server setup receiving less traffic.
The same thing can also be seen from its RAM usage. The website consumed only 210.9 MB of 1024 MB RAM which is more than a half lower than the RAM usage of my previous server setup.
Please do not mind about the disk space which is smaller since there was no big files yet stored in the server (backups). It was a brand new VPS.
Here are another traffic and server performance stats:
Screenshot pics above were taken few hours later after the earlier screenshot pics above. Obviously the number of online users was less and hence the system resource consumption was lower.
Following is a screenshot pic of the latest traffic stats of the same website before it was eventually sold:
28k unique users per day was the highest number the website received.
Server stats when vestaCP generated backups:
I still have the same conclusion as my previous one that VestaCP doesn’t consume much load on system resource. The performance is even better when using Nginx as a pure webserver instead of Apache in the backend. The performance can even be better if combined with in-memory object caching like Redis to reduce database query.
To sum up, the stats above show that even an OpenVZ vps having 1GB RAM can easily handle 26k – 28k unique visitors per day without single blip and lag. In fact, not even a half of server specifications was consumed by Vestacp to serve the website to thousands of visitors worldwide.
I built the server above using 1GB RAM which is a half of my previous server specs (2GB RAM) based on my calculation from my previous review. Yes I said it could also possible to host the website with that amount of traffic in a VPS having 768MB RAM and 2 CPU cores. However, VestaCP will do a cron job at least once per day (depends on your setup) to create a full backup of all accounts and website – that’s due to backup process was taken on a live server so the load was from backup progress plus visitors traffic. Unfortunately, that consumes a lot of system resource if the number and the size of all files are mostly big. Therefore, I decided to host the website on a VPS having 1GB RAM with 4 cores of CPU.
Vestacp using default configuration is great but Vestacp using LEMP stack (LEMP: Nginx + Php-fpm) is awesome! It can perform way better with less system resource usage than standard Vestacp install (LAMP + Nginx).
VestaCP is, unlike what most people thought, not as heavy as many hosting control panel in terms of server’s resource usage. It’s pretty lightweight and on top of that it’s free. However, the result may vary depending on your website configuration (like the number of scripts executed, etc).
That’s all. I hope this will give you a basic clue to consider Vestacp LEMP stack to host your website having thousands of visitors. I believe you may also have a basic clue on deciding VPS specifications needed to host your website. Lastly, you may also consider whether to use KVM or OpenVZ since both have different style of virtualization and hence will affecting how your server behaves. Any suggestion or idea? Do not hesitate to drop comment below. Thanks.