This weekend we had a chance to test out high-bandwidth Wordpress blog set-up configurations and performance. We had a customer that landed multiple Digg front page stories and we had to tune the server to deal with the high peak time traffic.

For best performance we usually deploy Nginx and tie it together with Apache as a back-end for PHP processing, memcached, super cache and do a lot of rewriting rules and other optimizations.

The server is powered by one CPU Quad Core 5430 series processor, with 2GB RAM and SATA drives, runs on a SuperMicro server board. It’s a powerful box that can handle traffic well if correctly tuned and optimized.

We were running the latest Wordpress blog software with some custom rewrites done on the front end Nginx daemon (front end proxy). All static content was served by Nginx and all PHP queries were forwarded to Apache 2 version compiled from source as well as latest PHP 5.2.6 loaded as a module.

Nginx front end, Apache + PHP, Super Cache, some custom rewrite rules:
Requests done: 1000, concurrency 30 threads

Server Software: nginx/0.7.11
Server Hostname: www.*****.COM
Server Port: 80

Document Path: /
Document Length: 340611 bytes

Concurrency Level: 30
Time taken for tests: 16.652752 seconds
Complete requests: 1000
Failed requests: 883
(Connect: 0, Length: 883, Exceptions: 0)
Write errors: 0
Non-2xx responses: 883
Total transferred: 190501217 bytes
HTML transferred: 190245813 bytes
Requests per second: 60.05 [#/sec] (mean)
Time per request: 499.583 [ms] (mean)
Time per request: 16.653 [ms] (mean, across all concurrent requests)
Transfer rate: 11171.49 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 38 189.7 27 3032
Processing: 131 452 464.8 283 3876
Waiting: 3 70 339.9 33 3042
Total: 156 490 500.0 311 3932

Percentage of the requests served within a certain time (ms)
50% 311
66% 418
75% 559
80% 632
90% 899
95% 1150
98% 1608
99% 3677
100% 3932 (longest request)

Nginx + FastCGI, running spawn-fcgi from Lightspeed distribution with 30 child threads, all static content served by Nginx and PHP served by PHP 5.2.6 php-cgi version (custom compiled from the source of course).

Server Software: nginx/0.7.11
Server Hostname: www.*****.com
Server Port: 80

Document Path: /
Document Length: 170281 bytes

Concurrency Level: 30
Time taken for tests: 103.429538 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 900
Total transferred: 170518100 bytes
HTML transferred: 170281000 bytes
Requests per second: 9.67 [#/sec] (mean)
Time per request: 3102.886 [ms] (mean)
Time per request: 103.430 [ms] (mean, across all concurrent requests)
Transfer rate: 1609.99 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 1748 3076 492.0 3035 4844
Waiting: 768 1673 370.9 1659 2948
Total: 1748 3076 492.0 3035 4844

Percentage of the requests served within a certain time (ms)
50% 3035
66% 3248
75% 3405
80% 3496
90% 3732
95% 3943
98% 4192
99% 4398
100% 4844 (longest request)

As you can see Nginx + Apache, PHP, Super Cache was the clear winner - no questions asked. I have no idea were did error requests pop up (I just noticed it while pasting the benchmark output in this thread) for the first case.

Conclusion: we will stick with Nginx as a front-end proxy serving all static content while PHP processing forwarded to Apache web server running on the same server (using worker), running Super Cache and doing as much rewrites and file checking using Nginx for best performance. Apache is a big resource hog, however, our tests show it still outperforms running PHP scripts via FastCGI.

I would like to note that running PHP as a FastCGI required slightly lower memory usage, however the CPU load shoot up and I was not sure if we could handle Digg traffic that easily. Enjoy!

With more and more complicated sites coming to the internet, you can create functional and attractive websites. When you receive proposals from your developer, you can choose LAMP which is the best technology available today. Today internet has large number of opportunities for creation and management of a website. Now you can build a website absolutely free and open source with Linux Apache MySQL PHP, popularly known and abbreviated as LAMP, a powerful and common bundle of technology components.

The combined components of LAMP viz., Linux is a very popular operating system; Apache is a web server, MySQL is a database and PHP is a scripting language. Choosing LAMP is the best way for you to gain complete control and power over your web site. You can get started with the free scripts, examples etc., which are available on the web site, by taking help of tools and free editors. A web hosting company can make a good profit margin with less cost involved in it since LAMP is absolutely open sourced. Now you have got a big choice before you to choose from a large number of web hosting providers.

As there are good improvements in the installers for LAMP components, you can install them without difficulty. When you are able to debug, you can use PHP debuggers to write perfect code. LAMP is very strong in its performance, security and reliability and is considered to be the best architecture to serve the web pages. LAMP will function as an excellent platform for your web development needs. You will benefit from the major advantages of LAMP which are open source, ‘geeky’ community supported and also of low cost compared to other technologies. PHP has a simple web integration and Apache is known for its security features. With LAMP you can run a dynamic server as well as website. With this combined LAMP technology you can establish a good software distribution package. You can acquire the components at a very low acquisition cost. LAMP allows you to use the web browser to execute program and receive static and dynamic content.

By using the scripting languages, you have got the benefit of efficient and easy manipulation of various text streams. You can use the bundle software LAMP as a best alternative solution to a commercial package. The popularity of LAMP is on the increase as it is available as free software.

If you are planning architecture for a very large online service or website, it’s recommended you avoid control panel software from the very beginning. If you intend to run a web-based service, why do you need running email, DNS and many other services on the same server? How about scalability and performance tuning when load and visitors increase?

The fewer services you run on the server, the harder it is to exploit, and the more system resources will be available for website hosting and script processing. Most web hosting control panels run a lot of software - altering the default configuration of Apache and other software may stop the control panel from running.

For top performance and scalability, you should use Linux, Apache, MySQL and PHP (LAMP). It’s all open-source and reliable, and it runs high-load websites such as LiveJournal, Wordpress.com and many others. As with all open-source technologies, it’s much easier to scale in the future and offers great flexibility - caching, full control over headers (setting expires), application optimization and much more.

When the load grows, you can easily split a MySQL server load to a fully dedicated MySQL server. Afterward, you can install reverse proxy solution or run a proxy server in front of your website to lower the load and scale horizontally by adding multiple servers that process PHP scripts and master-slave MySQL configuration with replication. For MySQL query caching, you can use memcached on multiple servers - this will offload MySQL database servers greatly.

We will go into more detailed tuning of LAMP servers in the near future.

I bet you have already heard about MogileFS if you are reading this article. MogileFS is an open-source and distributed file system that offers many good properties and features that are hard to find in some of the expensive and proprietary file systems currently available.

MogileFS is a perfect choice for your next storage system if you are planning to build a high-scale service with large storage requirements that is capable of being distributed to multiple servers and low-cost hard drives. It features excellent fail-over capabilities that can be set up using Linux open-source HA project - and there are quite a few projects and solutions are available. MogileFS high-availability storage can be run on simple PC hardware in non-RAID configuration. No hardware RAID is required, because MogileFS provides full fail-over - it replicates data between multiple devices. If one server dies the MogileFS continues working without problems. This saves thousands of dollars and provides HORIZONTAL SCALABILITY from small to large projects that require large storage space and high availability at the lowest possible cost.

You can set up MogileFS replication based on predefined classes and replicate files that are important. Files that are generated from the sources - for example, resized thumbnails - can be easily regenerated from your applications if the disk or server hardware fails.

MogileFS is not POSIX compliant and thus must be implemented in your applications from the very beginning. Multiple APIs are available for PHP, Perl and Python languages, and implementation is quite trivial.

You only need a minimum of two servers to run MogileFS - trackers can be run on the same server where storage nodes are running; however, 4 boxes are preferred and trackers need to be set up in high availability.

MogileFS can be set up in any number of storage servers horizontally that provide high-availability and load balancing, and it is a much better alternative to the widely used NFS, which has many problems.

Have you seen a webpage that starts to load somewhat strangely in your browser and after a couple of seconds the design changes? Or the page loading stalls for a few seconds and then loads fine?

It’s important to correctly position the external file calls to Stylesheet and JavaScript files.

Rule #1. Move all JavaScript external file calls to the bottom of your HTML code.

Rule #2. Move all StyleSheets external file calls to the top of your HTML code.

There are of course a few exceptions - for example, if you have a specific Javascript code that calls up an ad or specific block to display. In this case you will call the external file from the right place in your source. Another case can be some specific timer that can’t have a delay until the full page loads.

Always remember to have as few external include calls as possible. The more website content that can be cached, the better speeds it will provide, generally.