Archive | Web Server Performance Tuning

RSS feed for this section

Load Balancing Virtualmin WordPress Hosting Server with Varnish on AWS

I am creating a true load balancer topography for a WordPress hosting server, if it needs to scale up beyond what the current system can handle.

Scaling Levels

The current system is the “admin” path shown in the diagram, with no CDN or Load Balancing. It will handle a lot of traffic, but it is somewhat vulnerable to failure and overload. A simple and inexpensive extension of this system is to add CloudFront CDN, the “beta users” path.

For ultimate reliability and speed, I propose the “users” path: This will take most load off of the Virtualmin/Apache and Webmin/MySQL servers, because the user will be interacting only with CloudFront CDN and Varnish Caching Servers.

Load Balancing

The Load Balancing layer can be deployed separate from the current configuration, with DNS change to Route 53 for domains that require Load Balancing. If DNS routing for a domain goes to the Elastic IP, that traffic will interact directly with the primary Virtualmin/Apache server, which is OK for beta stage.

Traffic via Route 53 will be served from the Varnish instances, which will be load balanced, in multiple Availability Zones, and will serve cached WordPress pages as static HTML.

W3 Total Cache coordinates Apache and Varnish to provide updated disk-cached pages, and some data objects. CloudFront CDN pulls linked images, css, js, etc. from Apache via the W3 disk and opcode caches.

Redundancy and Fault Tolerance

More fault tolerance, speed and redundancy can be created via RAID10 arrays of multiple EBS Volumes, attached to the Virtualmin and Webmin instances. Creating a Storage Area Network for these volumes will provide shared /home and /var for the primary and slave instances.

Slave Server pairs for Virtualmin/Apache and Webmin/MySQL can be created to respond in round-robin fashion to the Varnish requests. With AWS Auto-scaling, more instances can be created on-demand if load on the backend servers is too great.

EBS snapshots of primary database server and web server will provide speedy recovery from catastrophic failure.
S3 backups of virtual domains on the primary Virtualmin/Apache server will provide speedy restoration of broken code or loss of files.

Be aware that creating a system with all of the elements I have described could be very expensive, and probably not necessary unless traffic is in the millions.

Website Workflow

WordPress sites:

At Soft Launch (client approval or beta):

  • Point A record to Elastic IP
  • Set up W3 Total Cache with CloudFront and Varnish, but do not deploy

At Public Launch:

  • Deploy W3TC
  • Point A record to Route 53, or set name servers to Route 53
Incoming search terms for the article:
Comments { 3 }

Punk Rock Music Community

Punktastic.com is a community powered site that covers punk music in Britain, but is poised to go worldwide. They cover punk and hardcore shows and festivals, and provide album reviews, video interviews and more.

With a growing audience and user base, Punktastic needed a more reliable and robust web server, so they made the move to a dedicated CentOS 5 series web server with 3GB RAM. While this is a relatively low-end box, it has plenty of horsepower for a single WordPress site and phpBB3 forum.

Punktastic.com web site

For this GIG, I soloed on…

  • transferring the site from a WAMP development server to the live LAMP server
  • configuring an active firewall to block the baddies
  • installing monitoring and administration tools
  • tuning Apache and MySQL for high traffic
  • integrating APC PHP Cache to speed up web pages and provide better concurrency

Loud Fast Rules.

Incoming search terms for the article:
Comments { 0 }

WordPress with W3 Total Cache on Nginx with APC (Virtualmin)

Virtualmin now includes support for Nginx web server. I deploy many WordPress sites with W3 Total Cache and APC Alternative PHP Cache, so I was very interested to see how Nginx performance compares to Apache for WordPress, and whether APC and W3TC would play nice with Nginx.

I prefer to install WordPress in public_html/wordpress for ease of development, compatibility with other scripts, etc. Accordingly, the suggested configuration is for WordPress installed in a subfolder. This info also assumes you have successfully installed APC Cache on your server, and set up a clean install of Virtualmin with Nginx as the Alternative Web Server. Switching from Apache to Nginx later is difficult, as is transferring apache virtual server backups. Best to start fresh and build from scratch.

Testing the Virtualmin Nginx Modules

Virtualmin does not support Nginx and Apache together, and there is no easy migration from Apache to Nginx, so it is suggested to begin with a fresh install of Virtualmin with no existing accounts.

If you would like to experiment with Nginx, and you already have a Virtualmin Pro license, you are permitted to set up Virtualmin on a second server for testing and migration. I run the extra Virtualmin Pro system on a VPS that I use for backups, slave DNS, and testing.

The Nginx modules are also available for the free Virtualmin GPL version. To install the modules, go to Virtualmin Package Updates (wbm-virtualmin-nginx and wbm-virtualmin-nginx-ssl).

WordPress Plugins for this Setup

  • W3 Total Cache — adds opcode cache, minification, browser cache and page cache capabilities to WordPress… and it works with Nginx. Works best with Alternative PHP Cache to provide opcode and database cache. Setting APC for all caches works easiest with Nginx… setting to file caching introduces URL rewrite errors… See W3TC Settings information below for instructions on how to implement File caching.
  • nginx Compatibility — makes WordPress more compatible with Nginx, allows use of permalinks without /index.php/

Configuring Nginx for WordPress pretty URL Permalinks

The nginx Compatibility plugin has support for pretty URLs, but you must configure Nginx to use them. You should add or edit the following URL path locations to nginx.conf for your virtual domain… either by direct edit, or via URL Path Locations in Virtualmin > Services > Configure Nginx Website (see attached image…). This config is for WP installed in /public_html/wordpress, so you will need to omit or change /wordpress if WP is installed in a different directory.

location ^~ /files/ {
rewrite /files/(.+) /wordpress/wp-includes/ms-files.php?file=$1 last;
}
location @wordpress {
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_NAME /index.php;
}
location ~ \.php$ {
try_files $uri @wordpress;
fastcgi_index index.php;
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}
location ^~ /blogs.dir/ {
internal;
root /home/username/public_html/wordpress/wp-content;
}

Adding APC Support for a Virtual Domain

Because Virtualmin’s implementation of Nginx uses php-fastcgi, each virtual domain will load its own php.ini file, so you can add the APC directives to that file (/home/domainname/etc/php5/php.ini)

Add the following to php.ini (adjust to your requirements)
[APC]
extension = apc.so
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 32M
apc.optimization = 0
apc.num_files_hint = 256
apc.user_entries_hint = 1024
apc.ttl = 0
apc.user_ttl = 0
apc.gc_ttl = 600
apc.cache_by_default = 1
apc.filters = ""
apc.slam_defense = 0
apc.use_request_time = 1
apc.mmap_file_mask = /tmp/apc.XXXXXX
apc.file_update_protection = 2
apc.enable_cli = 0
apc.max_file_size = 2M
apc.stat = 1
apc.write_lock = 1
apc.report_autofilter = 0
apc.include_once_override = 0
apc.rfc1867 = 0
apc.rfc1867_prefix = "upload_"
apc.rfc1867_name = "APC_UPLOAD_PROGRESS"
apc.rfc1867_freq = 0
apc.localcache = 1
apc.localcache.size = 256
apc.coredump_unmap = 0
apc.stat_ctime = 0

Reloading PHP-fastcgi processes after changes to php.ini

You will need to reload the php-fastcgi processes if you change php.ini. Luckily, Virtualmin creates service scripts for each virtual domain, which you can use to reload PHP.

The service scripts are located in /etc/rc.d/init.d.

php-fcgi-domain1.com
php-fcgi-domain2.com

Script allows stop, start, restart
e.g.
service php-fcgi-domain2.com restart

The service may also be restarted via Webmin > Services > Bootup and Shutdown

Memory Considerations

PHP FCGId will launch the number of sub-processes you specify in Virtualmin > Server Configuration > Website Options, so beware of the memory overhead if you specify a large number, because each will consume the amount of memory specified in  apc.shm_size. You may need to experiment with this value, depending on your server’s memory and potential traffic.

Virtualmin explains: “When PHP scripts for this domain as run via FCGId, the number of PHP processes set in this field will be kept running at all times to serve requests. You can increase this from the default of 4 to improve PHP script latency, or decrease it to reduce memory use. Setting it to None will cause PHP processes to be launched only as needed on demand, and to be cleaned up after some period of inactivity.”

Nginx support on Virtualmin is working well, and it is reported that the lead developer, Jamie Cameron, is working on a php-fpm implementation, which should increase performance and lessen memory requirements. Let’s hope this rumor is true!

W3 Total Cache Settings

Provided you use the nginx.conf settings described above, using APC cache for all W3TC categories of cache/minify/etc. will work with no additional changes to the conf file. However, if you wish to choose Disk cache for page and/or minify cache, URL rewriting will not work properly on Virtualmin. You must include the location {…} directives in the nginx.conf created in your public_html root by W3TC, and add them after the location {…} directives described above.

You can do this either by copying the directives and pasting into /etc/nginx/nginx.conf, or (better) by using an include statement:

[...]
location ^~ /blogs.dir/ {
internal;
root /home/username/public_html/wordpress/wp-content;
}
include /home/username/public_html/nginx.conf;
[...]

However, remember you will need to restart NginX web server after making changes to the W3TC configuration, because these will over-write the local nginx.conf file.

Conclusion

Sorry, no benchmarks. See my example/test site here.

Nginx support on Virtualmin is working well, though I don’t see much improvement over Apache in terms of initial index page load, or time to first byte on the WordPress test site I created.  Cached and subsequent pages load very quickly, so it looks like there is an overall improvement. All WordPress functions seem to work well: comments, image uploads, etc. are no problem. I am interested to see if there is improvement with other scripts, especially phpbb3.

Incoming search terms for the article:
Comments { 11 }

Apache and MySql Performance Tuning for High Traffic Website

SoccerNews.com is a high traffic WordPress site with over 600,000 unique visitors and over 2,000,000 page impressions per month. It is a content republisher and aggregator, presenting custom XML feeds for (what else?) soccer news from all over the world. The site has a very active user base, providing content in the forms of editorials and comments on news items. Advertising and sponsored referrals provide the revenue stream.

SoccerNews.com website

SoccerNews.com website

I was contacted by the publisher after responding to a plea for assistance in a WordPress.org support forum. Though the site was running on a dedicated server with 8GB RAM, it was crashing frequently under load. The developer tried implementing APC Alternative PHP Cache and W3 Total Cache, but these measures turned out to be incompatible with some of the custom PHP code and the software architecture of the server. Haphazardly implementing randomly suggested “solutions” had actually made the problems worse, resulting in an “own goal” that brought down the server.

I did an assessment of the software, hardware and traffic load and found that there were many improvements to be made. Among the changes:

  • Implemented a Stateful Packet Inspection firewall and Login Failure Daemon to block malicious IP addresses, malware servers, bad bots, content scrapers, etc. Many of the problems leading to site crashes were due to constant bad bot traffic, security probes and Denial of Service attacks. Connection Tracking in the firewall now limits the amount of resources a single legitimate IP address can monopolize, in addition to blacklisting attackers.
    • This is the first step to proper web server performance in today’s Internet climate. Popular sites that do not have a solid security and load balancing strategy are subject to crippling traffic from the Internet’s millions of malicious and compromised servers and personal computers.
  • Reconfigured Apache web server, PHP and MySQL to better utilize the server’s horsepower. Default configurations were limiting the number of concurrent user sessions the server could handle. Changed PHP to run as FastCGI (fcgid) and recompiled Apache to better handle the needs of a high traffic WordPress site. Configured a large MySQL table and query cache based on performance and load testing.
  • Configured Amazon CloudFront Content Distribution Network, page cache, browser cache, and object cache with the WordPress plugin, W3 Total Cache. Due to the sheer number of ad scripts being served per page, there were inevitable JavaScript and PHP conflicts, but W3TC is very flexible and was able to handle the task.
  • Suggested a scheduled, offsite backup strategy that would utilize existing resources, and eliminate the need for a 3rd-party backup solution that was causing more load issues and costing $45.00 per month.
Now the site is stable and fast, and is ready for very high traffic. With World Cup Brazil coming up in 2014, the site will definitely see a huge amount of users. Future plans include changing the architecture of the server to simplify the background processes and implement APC Alternative PHP Cache, or a caching web server front end.

Results? I’ll let the publisher speak to that!

The site has been as good as “flawless” since, with no downtime, and we couldn’t be happier. Everything is running smoothly and it’s a great relief knowing that we made the site faster, safer and more reliable. The site feels a lot more stable and faster. So you’ve done a great job. 

– Kim Vincenzius, StarScape LLC

Incoming search terms for the article:
Comments { 0 }