= Hosting Server Setup Recommendations = It was noticed that many server's default setup is very inefficient. It leads to poor script performance and in some cases hosting can terminate your account due to heavy load. This document covers very basic recommendations on how to improve your site performance by slightly changing your server configuration. This 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 this settings on the server, so whole server will run faster. You need root access to the server and have some skills on how to connect to the server using SSH terminal and know some basic command line tools, like navigating through directories and editing files. '''Remember, making wrong changes can bring your server down !''' == Before Start == Always backup old data, so you can always return to 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 worth. I suggest to install "[http://munin-monitoring.org/ Munin]" server monitor, it is available as WHM plugin, you can install it from WHM panel -> cPanel -> Manage Plugins -> click "Install and Keep Updated" near Munin logo and press "Save" button at the bottom of the page. After installing link to Munin appears in "Plugins" section of WHM panel, please allow up to 10 minutes until it generates pages with graphs for you. == 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 phpMysqlAdmin tool (in most cases it is in your WHM panel -> SQL Services -> phpMyAdmin). Then click "Variables" tab. "query cache size" must be at lesat 16M, "query cache type" must be ON and "query cache limit" value should be around 1M. Example of good configuration: [[Image(hssr-mysql-1-query-cache.jpg)]] After you realized that you need to change these settings you need to edit "my.cnf" file on your server (in most cases it in in "/etc" folder) and add the foollowing lines in "[mysqld]" section of the file, if the same configuration options already exists it is better to comment out old ones (with 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, you can do it from WHM panel or from command line, most common command line for linux servers is: {{{ /etc/init.s/mysql restart }}} This 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 exact values varies from server from server, for example for dedicated or VPS server with 1Gb RAM and one dolphin 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 "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 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 some 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 restarted this data is collected from the scratch. This is an example on how many queries becomes cached after introducing "query cache": [[Image(hssr-mysql-2-queries-day.png)]] 1 day is showed on the graph, in the beginning cache was disabled, then cache was enabled - pink zone shows SELECT queries which are taken from cache. So, benefits are obvious ! == PHP == There are many setups options here, there are advantages and disadvantages between all of them. So choose most suitable for your situation. PHP is a part of webserver and it is difficult to describe PHP without webserver or related to different webservers, so Apache is considered as webserver in this section. Most common setups are described, but there are more complex setups maybe available. === mod_php (dso module) === PHP is working as module for webserver. This most common and simple setup. You can check phpinfo() to see if you have this setup: [[Image(hssr-php-1-dso.jpg)]] This setup works fast because web-server don't need to load PHP interpreter each time, it works as part of web-server. You can even speedup it by installing [http://en.wikipedia.org/wiki/PHP_accelerator opcode cache extensions for PHP], we recommend [http://eaccelerator.net/ eAccelerator], because you can get advantage of shared memory cache since Dolphin 7.0.3 which offer eAccelerator. The problem maybe on shared hosting, because PHP scripts are executing under the same web-user (nobody or apache as usual) and one account owner can get access to nobody files of other account on the server, but it can be properly configured with correct "base_path" restriction to disable such access from PHP script. If you have VPS or dedicated server this is not a problem, since all sites on the server are yours. This setup considered to be secured, because in case of hacking attempt it is possible to upload files to nobody directory only and modify nobody files only, no risk to overwrite or modify index.php file for example (if it has correct permissions) __Advantages:__ * speed * security * easy install * opcode cache extensions support __Disadvantages:__ * maybe insecure on shared hosting __Conclusion:__ if you already have such setup it is ok to leave it, but consider to install opcode cache extension. === CGI/suPHP === PHP is working in CGI mode (suPHP is the same CGI with exception that php script is running under particular user). Server API in phpinfo() looks like this in this setup: [[Image(hssr-php-2-cgi.jpg)]] This is most inefficient setup, webserver have to load PHP interpreter each time, especially when small PHP files are executed - time overhead can be up to 2500% (25x time slower). Even worse that 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 shared hosting environment. But when attacker get access to your server - access to all files is open, any file can be modified/removed in any folder, so it maybe more dangerous result in case of hack attempt. __Advantages:__ * all files are always handled under one owner, so you don't need to bother about files permissions * PHP settings can be changed without web-server reload __Disadvantages:__ * slow * opcode cache extensions are not supported * insecure __Conclusion:__ it is better to switch to another setup if you have VPS or dedicated server. If you are on shared hosting try to ask to move your account to another server with another setup. If you have no choice - try to lower number of accesses to webserver: you can do it by uninstalling the following modules in Dolphin (they make periodic lightweight request to web-server): messenger, simple messenger, spy and disable floating member menu. Or at least increase time between requests. === FastCGI === PHP is working as separate server process. Server API in phpinfo() looks the same as in CGI/suPHP mode: [[Image(hssr-php-2-cgi.jpg)]] This setup is very flexible. There are different webserver modules which implement FastCGI interface. Also PHP has build-in support of this interface. In general this is best setup which provide great flexibility and speed, but the setup 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 specific user. It maybe complicated situation with opcode cache PHP extensions, if there are many process under different users are running, in this case each user will have own opcode cache, it means more security from one side, but high memory usage from another 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 the specific situation. * it maybe high memory usage with opcode cache extensions if there are several PHP processes under different users. __Conclusion:__ This is a best option in most situations. Just check how your site is functioning, maybe some things can be changed to increase speed and/or security of your site.