Hosting Server Setup Recommendations

Hosting Server Setup Recommendations for Optimal Cheetah Performance

Cheetah is a package of many scripts and it may perform very well only if the server is properly configured. Unfortunately, we have noticed that many server default setups are very inefficient, often leading to false assumptions about Cheetah performance. In some cases hosting providers terminate accounts due to heavy load, although traffic is insignificant. This document covers very basic recommendations on how to improve your site performance by slightly changing your server configuration. Our research shows that very poor and very good combinations of setups may lead to up to 2500% (25x) difference in execution times of certain files.

These recommendations are for dedicated or VPS server owners, however if you are on shared hosting and notice that your server configuration is inefficient, you can ask your hosting support to change these settings on the server, so the whole server would run faster.

You will need root access to the server and also some skills on how to connect to the server using SSH terminal and must know some basic command line tools, like navigating through directories and editing files.

Remember, making the wrong changes can take your server "down". So, be careful, backup everything you can and research more if unsure.

A fast and efficient server setup will lead to better page-load time, lower server resources consumption, smaller hosting bills, better search engine rankings and happier site visitors.

Before Starting

Always backup old data, so you can always return to the original configuration.

Before starting optimization, it is better to monitor your server performance before starting optimization and after, to see how things are changing, if it becomes better or worse. Try "Munin" server monitor, available as a WHM plugin, which you can install from the WHM panel -> cPanel -> Manage Plugins -> click "Install and Keep Updated" near the Munin logo and press the "Save" button at the bottom of the page. After installing, a link to Munin appears in the "Plugins" section of your WHM panel. Allow up to 10 minutes until it generates pages with graphs for you.

---

Table of contents:

• MySQL
• PHP
• mod_php (dso module)
• CGI/suPHP
• FastCGI
• Different PHP setups Benchmark
• Web-server
• Preparation
• Server side content compression
• User side caching for static content
• Conclusion

---

MySQL

---

First you need to check if "query_cache" is enabled on your server. It was noticed that 80% of all SELECT queries are taken from "query_cache" when it is enabled, so if it is disabled on your server

• mysql performance is 5 times slower !

To check this, go to the phpMysqlAdmin tool (in most cases it is in your WHM panel -> SQL Services -> phpMyAdmin). Then click the "Variables" tab. The "query cache size" must be at least 16M, "query cache type" must be ON and "query cache limit" value should be around 1M. Example of a good configuration:

After you realized that you need to change these settings, you need to edit the "my.cnf" file on your server (in most cases it is in the "/etc" folder) and add the following lines in the "[mysqld]" section of the file. If the same configuration options already exist it is better to comment out old ones (with the hash # symbol ) and add new ones near them:

[mysqld]
query_cache_limit = 1M
query_cache_size = 32M

You need to restart MySQL server to apply the changes, and you can do it from the WHM panel or from a command line,.. the most common command line for linux servers is:

/etc/init.s/mysql restart

These are the most critical configuration options. Other useful options should be enabled too - "key buffer size", "max heap table size", "tmp table size", "thread cache" are some of them. But the exact values varies from server to server. For example, for a dedicated or VPS server with 1Gb RAM and one cheetah site, these values maybe like this:

[mysqld]

query_cache_limit = 1M
query_cache_size = 32M

key_buffer_size = 64M

max_heap_table_size = 256M
tmp_table_size = 256M

thread_cache = 128

There is already a tool in phpMyAdmin which can help you with deciding what configuration values need to be changed. Go to phpMyAdmin and open the "Status" tab, look through this page and pay attention to red values. There is a comment near each value you can use as a guide in changing a particular MySQL option. During changing, remember that memory is always limited, so you need to increase the values adequately to your available RAM. Keep in mind that these values are collected during a period of time, so if you change some value it is better to wait at least 1 day until new data is collected for analysis. After MySQL is restarted, this data is collected from scratch.

This is an example of how many queries becomes cached after introducing "query cache":

1 day is shown on the graph. In the beginning, cache was disabled, then cache was enabled - the pink zone shows SELECT queries which are taken from cache. So, the benefits are obvious !

---

PHP

---

There are many setup options here, and there are advantages and disadvantages between all of them. So choose the most suitable scenario for your situation. PHP is a part of the webserver and it is difficult to describe PHP without the webserver or related to different webservers, so Apache is considered as the webserver in this section. Most common setups are described, but there are more complex setups that may be available.

mod_php (dso module)

This method is no longer supported. Hosting should be setup with PHP running as a PHP-FPM application.

CGI/suPHP

Although all of Cheetahs features should work using this setup. PHP-FPM is still recommended. PHP-FPM is now normally the default for most modern hosts providing Plesk or cPanel. You should not use this unless you have to.

PHP is working in CGI mode (suPHP is the same CGI with the exception that the php script is running under a particular user). Server API in phpinfo() looks like this in this setup:

This is the most inefficient setup. The webserver has to load the PHP interpreter each time, especially when small PHP files are executed - the time overhead can be up to 2500% (25x times slower). Even worse is if opcode cache extensions are not compatible with suPHP.

This is used on shared hosting to separate users from each other, so it is considered to be safe on a shared hosting environment. But when an attacker gets access to your server - access to all files is open, and any file can be modified/removed in any folder, so this maybe a more dangerous result in case of a hack attempt.

Advantages:

• all files are always handled under one owner, so you don't need to bother about file permissions
• PHP settings can be changed without a web-server reload

Disadvantages:

• slow
• opcode cache extensions are not supported
• insecure

Conclusion: it is better to switch to another setup if you have a VPS or dedicated server. If you are on shared hosting, try to ask them to move your account to another server with another setup. If you have no choice - try to lower the number of accesses to the webserver. You can do this by uninstalling the following modules in Cheetah (they make periodic lightweight requests to the web-server): messenger, simple messenger, spy and disable floating member menu. Or, at least increase the time between requests.

FPM/FastCGI

PHP is working as a separate server process. Server API in phpinfo() looks the same as in CGI/suPHP mode:

This setup is very flexible. There are different webserver modules which implement the FastCGI interface. Also, PHP has built-in support for this interface. In general this is the best setup which provides great flexibility and speed, but setting up can be a bit tricky. It can be run under any user, so it can be run under webserver user (nobody or apache, as usual) or under a specific user.

It maybe a complicated situation with opcode cache PHP extensions, if there are many processes under different users running. In this case, each user will have their own opcode cache - meaning more security from one side, but high memory usage from the other side.

Advantages:

• flexibility
• speed
• security (if properly configured)
• opcode cache extensions support
• enabled by default since PHP 5.3

Disadvantages:

• since there are a lot of ways to implement this setup, it may be difficult to tune it up for a specific situation.
• it may incur high memory usage with opcode cache extensions if there are several PHP processes under different users.

Conclusion: This is the best option in most situations. Just check how your site is functioning - maybe some things can be changed to increase speed and/or the security of your site.

Different PHP setups Benchmark

Tests were performed on the following environment:

• Hardware: Intel Pentium E2140 (1M Cache, 1.60 GHz, 800 MHz FSB), 1Gb RAM
• OS: Gentoo Linux
• Web-server: Apache 2.2
• PHP: 5.3.3
• Clean Cheetah.0.3 development version with default settings with all modules installed

Apache benchmark (ab) tool was used to measure performance:

ab -c 50 -n 200 -C memberID=1 -C memberPassword=XXX http://local-domain/local/path/index.php

It means 200 requests with 50 concurrency requests and cookies are set to simulate a logged in user. Total test execution time was measured - so the biggest value means the slowest execution time.

The following pages were tested:

• phpinfo() - performance of single and simple php script file execution time.
• XML.php - performance of periodic requests, like checking for updates in Flash messenger, simple messenger, member menu notifications, spy updates.
• faq.php - performance of simple cheetah pages, page with one text block.
• index.php - performance of complex cheetah pages with many blocks from different modules, most complex and slowest page in Cheetah is tested

Finally the result:

[[modules/deano/cheetah_docs/uploads/images/hssr-benchmark.jpg|File:Modules/deano/cheetah docs/uploads/images/hssr-benchmark.jpg]]

Conclusion: suPHP/CGI is slowest possible setup. More important is that it is 5x times slower for most frequent requests to XML.php and similar pages comparing to the fastest setup - FastCGI+eAccelerator or mod_php+eAccelerator. If you already have a mod_php or FastCGI setup you can easily install eAccelerator and get more than a 200% performance increase !

Also, from Cheetah.0.3 onward, there is built-in support for eAccelerator shared memory cache, so there is even more of a performance increase - not shown, because this test does not include this modification.

---

Web-server

---

The Web-server is most critical part, and optimizing it can give the most performance increase and leverage server load. There are many tweaks to the web-server, but the most critical optimization will be described.

We will consider the recent version 2.2 of Apache as the most frequently used web-server nowadays, however most of the options should apply to Apache 2.0 too.

If you need to configure Nginx web-server for Cheetah then please refer to How to setup Cheetah on Nginx webserver.

A new install of Cheetah with all Cheetah modules is used as test environment. Internal Cheetah JS/CSS files compression was disabled to show how to do it using your web-server.

Preparation

I suggest installing Firefox browser + Firebug extension for Firefox + Page Speed extension for Firebug.

Page Speed is a great tool from Google which shows a lot of optimization advices for the website. We will use it to check if a a particular optimization trick is enabled and/or to check if changes were applied to the website.

Also Page Speed gives every site an overall score. We will watch this score too to see how it will be increased after basic, but the most critical optimization steps are completed. So, in the beginning or the score is 64/100:

[[modules/deano/cheetah_docs/uploads/images/wso-0-preparation.jpg|File:Modules/deano/cheetah docs/uploads/images/wso-0-preparation.jpg]]

Please note: your score maybe different, due to different server configuration and different content on the site.

Server side content compression

Despite the fact that Cheetah.0.3 has built-in compression of JS/CSS files, this is still critical optimization step, because internal Cheetah compression compresses only one combined JS cache file and one combined CSS cache file - these two files are where compression is most important and where most of the file size reduction is possible.

Please note: compression is disabled automatically if CSS/JS cache is turned off.

Let's see the Page Speed analysis for compression for the Cheetah homepage:

[[modules/deano/cheetah_docs/uploads/images/wso-1-compression.jpg|File:Modules/deano/cheetah docs/uploads/images/wso-1-compression.jpg]]

Half a megabyte size deduction is possible ! It is about 70 seconds of waiting on a fast 56k modem connection speed. It is already a good reduction for the two most critical files - CSS and JS cache files - 400 kb is possible by default from Cheetah.0.3 on, but more optimization is possible. You need to enable mod_deflate for apache and tune it right (for Apache 1.3 mod_gzip do the same thing).

To check if mod_deflate is enabled on your web-server you can execute the following commands on your server:

apachectl -t -D DUMP_MODULES

and see if the deflate_module is listed in the output. Also, you can try to check phpinfo (if you have no access to command line):

[[modules/deano/cheetah_docs/uploads/images/wso-1-compression-phpinfo.jpg|File:Modules/deano/cheetah docs/uploads/images/wso-1-compression-phpinfo.jpg]]

If this module is installed you can begin to configure it. If not - then you need root access to the server to enable it. It is better to ask your hosting support to enable it on your server. If you have cPanel WHM it can be enabled using the EasyApache tool, but anyway it is better to perform this via your hosting support.

To configure mod_deflate you need access to the .htaccess file in your Cheetah root folder (root access is not necessary here). Insert the following code in your .htaccess file in the Cheetah root folder:

    # Insert filter
    SetOutputFilter DEFLATE
    
        # Netscape 4.x has some problems...
        BrowserMatch ^Mozilla/4 gzip-only-text/html
        # Netscape 4.06-4.08 have some more problems
        BrowserMatch ^Mozilla/4\.0[678] no-gzip
        # MSIE masquerades as Netscape, but it is fine
        BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
        # Don't compress images/archives/music/video/etc
        SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
        SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
        SetEnvIfNoCase Request_URI \.(?:avi|mov|mp3|mp4|rm|flv|swf|mp?g)$ no-gzip dont-vary
    
    
        # Make sure proxies don't deliver the wrong content
        Header append Vary User-Agent env=!dont-vary
    

It will enable compression for all files except some archives/movies/music/etc files.

After applying the above change, clear the browser cache and press "Analyze Performance" or "Refresh Analysis" button in Page Speed panel. The resulting score is 71/100 now, and the first, most important warnings go away:

[[modules/deano/cheetah_docs/uploads/images/wso-1-compression-result-score.jpg|File:Modules/deano/cheetah docs/uploads/images/wso-1-compression-result-score.jpg]]

User side caching for static content

This optimization permits static content to be cached in the user's browser, so the server will not be even asked for the most part of the site's content at all. It can save even more bandwidth and server resources in some cases. This type of optimization users "feel" more than all others. It can change a slow feeling site to lighting fast - without any other optimizations.

The following graph shows an example of introducing this type of optimization on one server:

[[modules/deano/cheetah_docs/uploads/images/wso-2-user-side-cache-graph.jpg|File:Modules/deano/cheetah docs/uploads/images/wso-2-user-side-cache-graph.jpg]]

Optimization was introduced in the beginning of August and you can see that the number of requests to the server reduced twice as much! This is not a Cheetah based site, but a Cheetah site can be even more optimized because there are more static resources in Cheetah than on this site. /p>

IIn Page Speed analysis this optimization comes next - "Leverage browser caching":

[[modules/deano/cheetah_docs/uploads/images/wso-2-user-side-cache-page-speed-before.jpg|File:Modules/deano/cheetah docs/uploads/images/wso-2-user-side-cache-page-speed-before.jpg]]

Not all files which can be cached in the browser are even listed, so there are a lot of them. This optimization is first on the screenshot because server side compression is already applied and is not shown.

To introduce this optimization for your site you need the mod_expires mod for Apache. You can check if this module already exists with the same command:

apachectl -t -D DUMP_MODULES

and see if the expires_module is listed in the output. You can check phpinfo too the same way as in "Server side content compression".

After you make sure that the module is available you can add the following code to your .htaccess file in the Cheetah root folder:

    # enable expirations
    ExpiresActive On
    # expire images/css/js/swf files after a month in the client's cache
    ExpiresByType application/x-shockwave-flash "access plus 30 days"
    ExpiresByType text/css "access plus 30 days"                
    ExpiresByType text/javascript "access plus 30 days"         
    ExpiresByType application/javascript "access plus 30 days"  
    ExpiresByType application/x-javascript "access plus 30 days"
    ExpiresByType application/x-gzip "access plus 30 days"                                       
    ExpiresByType image/gif "access plus 30 days"
    ExpiresByType image/jpeg "access plus 30 days"
    ExpiresByType image/png "access plus 30 days"
    ExpiresByType image/x-icon "access plus 30 days"
    ExpiresByType image/vnd.microsoft.icon "access plus 30 days" 

It will cache all images/css/js/swf files for 1 month in user's the browser cache.

After applying the above change, clear the browser cache and press "Analyze Performance" or "Refresh Analysis" in Page Speed. The resulting score is 76/100 now, and the second most important warning goes away:

[[modules/deano/cheetah_docs/uploads/images/wso-2-user-side-cache-page-speed-after.jpg|File:Modules/deano/cheetah docs/uploads/images/wso-2-user-side-cache-page-speed-after.jpg]]

A common Cheetah page has about strong>200 Kb of static resources that can be cached in a user's browser. Most important is that the number of files is about 60 - a browser can not load all these files in parallel and has to load 2-3 files in parallel. This means that loading 60 files in a total size of 200 Kb with 2 simultaneous loads usually take 10-20 seconds on a good DSL connection and 45 seconds on a good 56K modem connection.

Conclusion

After applying above web-server optimization tips your web-server will breath easier and most important is that your users will feel it even more!

The benefits shortlist:

• your users will load approximately 700 Kb less data on each page load
• your users will wait approximately 30 seconds on DSL (2 minutes modem connection) LESS each page load
• visible site response time will be much better
• users will surf more pages at the same time
• users will surf more pages in total - since they are loaded faster
• users bandwidth economy
• better and faster search engines crawling
• better positions in search engines
• server bandwidth economy
• less requests to the server
• server load will be decreased
• everyone will be happier :)

IMPORTANT

This guide is a work in progress. We will be adding more information as soon as we have new results and findings. Checking back once in a while is highly recommended.

While server setup is very important, we realize that there is a lot of optimization that can be done in Cheetah. We will continue working on every piece of code in Cheetah to make it the fastest and the most efficient CMS in world.