Posts Tagged ‘apache servers’

Some Apache performance optimizations to do on brand new installed Linux servers – Apache performance tuning tips

Wednesday, December 12th, 2012

good tips to optimize Apache webserver  on Debian CentOS and RHEL Linux for better performance and faster website openings

It is a good idea, on any productive server which is supposed to run Apache + PHP on Linux to do some initial Apache configurations which will guarantee a better WebServer performance and improved Apache client thoroughput. On every each and other new configured Linux server planned to server as an Apache + some database backend, I routinely make this tune ups even without thinking. The reason I do it is time and experience proofed this optimizations works like a charm and almost in 100% of cases they can only improve situation with the server, decrease the general expected load and thus save costs for potential hardware. Besides that the few config options which I'm about to suggest in this article guarantee improved WebPage opening times and most of times overall Apache response times. The consequence of embedding the optimizations has a straight influence on Google / Yahoo PageRanking as it is not a secret most (if not all) Search Engines, rank with a Higher PageRank webpages which load up for lower opening times.


1. Change values for KeepAlive, Timeout and KeepAliveTimeout

First thing to change in Apache default config is reduce the default value set for KeepAliveTimeout and KeepAlive and TimeOut

a. Reducing  KeepAliveTimeout

  a.In Debian, Ubuntu servers this value has to be changed in /etc/apache2/apache2.conf

b. in RHEL, Fedora and other RPM based distros check in /etc/httpd/conf/httpd.conf

By default KeepAliveTimeout is set to 15 – KeepAliveTimeout 15. 15 Seconds is a long delay and on a by Apache servers it is very likely you will have hundreds if not thousands of Apache forks or internal threads, keeping still open for clients which already navigated off from the website or websites hosted and served by Apache.

Taking this in consideration, most of the times I prefer setting the KeepAliveTimeout value to 7 secs – i.e.;

KeepAliveTimeout 7

even to some hosts, where you have a well tested PHP Code or just serving static files it is a good idea to decrease it to 5 secs (this is much more risky and likely to create problems, I set it to 5 secs in a vary rare occasions, anyhow you might want to experiment)

Bear in mind that in some cases, where page execution (lets say a PHP script) takes longer to execute than 7 seconds clients might end up with empty pages as Apache will drop off the opened TCP / IP connection to remote client. Thus for some people who run badly written websites with PHP scripts which take long time to execute lowering default KeepAliveTimeout might have negative results. Therefore as a rule of thumb if you reduce the KeepAliveTimeout, be sure to monitor closely with the website testers team or via some website feedback form if the website continues to perform okay for end clients, if not just tune up KeepAliveTimeout to a value with which the website works fine. Other reason why KeepAliveTimeout is so good in almost all cases to reduce is by simply closing quicker opened network connections, less Apache childs keeps loaded in memory and therefore more memory is available for eventual new clients  connecting.

Here is also KeepAliveTimeout explained as pasted from a Debian apache2.conf:

# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#KeepAliveTimeout 15
KeepAliveTimeout 5

b. Turn on KeepAlive

By default most Linux distros came with KeepAlive setting turned off, switch it on;

# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
# KeepAlive Off
KeepAlive On

c. Reduce the amount for TimeOut of client inactivity

Default TimeOut setting is set to 300 seconds!
A good value to reduce it to is 40 or 80. 80 value is less likely to create content serving unexpected interrupts. On most servers I just set to 40 as so far this value works well for me.

# Timeout: The number of seconds before receives and sends time out.
#Timeout 300
Timeout 40

2. Enable Apache mod-expires – WebServer content caching

debian:~# ln -sf /etc/apache2/mods-available/expires.load /etc/apache2/mods-enabled/expires.load

Depending on Deb or RPM based Linux distro in Apache config (apache2.conf or httpd.conf), add following mod_expires directives;

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault A86400
ExpiresByType image/x-icon A2592000
ExpiresByType application/x-javascript A2592000
ExpiresByType text/css A2592000
ExpiresByType image/gif A604800
ExpiresByType image/png A604800
ExpiresByType image/jpeg A604800

One note to make, here that on some websites based on Smarty, Zend PHP Framework etc. PHP frameworks mod_expires might cause some troubles, however in 70-80% of the cases just enabling it causes no harm to the overall website functionality. Be sure to test it well if you enable it and don't blame me if it cause you issues.

3. Set ServerRoot and  Raise-up ServerLimit and MaxKeepAliveRequests  directives

By default the value set for ServerLimit is too low for productive servers (256 mpm_prefork Apache childs maximum), thus for servers which are expected to get in parallel few hundreds of unique IP clients I usually set it along with ServerRoot like so;

# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
# NOTE!  If you intend to place this on an NFS (or otherwise network)
# mounted filesystem then please read the LockFile documentation (available
# at <URL:>);
# you will save yourself a lot of trouble.
# Do NOT add a slash at the end of the directory path.
#ServerRoot "/etc/apache2"
ServerRoot "/etc/apache2"
ServerLimit 10600

Another good practice is to set MaxKeepAliveRequests which will be handled by Apache forked child to a high value but not to 0 (which will make once forked Apache childs to never die – making them likely to mess up assigned memory due to memory leaks or Apache bugs). On a productive servers I set values from  5000 to 50000.

# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
MaxKeepAliveRequests 50000

4. Enable mod_rewrite Apache support

This step is not optimizing Apache performance but it is useful to enable mod_rewrite, as there is almost no website today which doesn't use mod_rewrite via .htaccess passed directives.

debian:~# ln -sf  /etc/apache2/mods-available/rewrite.load /etc/apache2/mods-enabled/rewrite.load

5. Adjusting default values of StartServers, MinSpareServers, MaxSpareServers, MaxClients and MaxRequestsPerChild  for mpm_prefork

Default config values set for mpm_prefork, are for a tiny home server, depending on  the server amount of memory and CPU power – StartServers, MinSpareServers, MaxSpareServers, MaxClients and MaxRequestsPerChild – should be carefully tailored and tested with Apache Benchmark little tool and Siege or any other benchmarking tool before WebServer is made publicly accessible.

Default values from apache2.conf are like so:

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   0

A good configuration for a productive server with 24GB of Memory and 8 CPUs x 2.13 Ghz (about 17Ghz Computing Power) would be for exmpl.:

<IfModule mpm_prefork_module>
    StartServers          2000
    MinSpareServers       600
    MaxSpareServers      800
    MaxClients          3600
    MaxRequestsPerChild   10000

5. Intall and Enable Eaccelerator

On almost all servers I install I install immediately after basic Apache + PHP + MySQL packages, Eaccelerator. Eaccelerator helps utilizing better server free memory and significantly accelerates Apache pages serve time

I've earlier blogged on How to install Eaccelerator to decrease server CPU load and increase page serving performance here

6. Disable Server Side Includes ( SSI ) support

I've earlier blogged how to disable Apache SSI on Debian Linux – you can read here. The change SSI will make whether off is not so big so even leaving it on  is not a big deal.

7. Remove and Purge Suhosin apache module

suhosin is useful module that tightens Apache security, however for me it has earlier create a lot of issues and it is my personal view that life is better without suhosin. I've earlier stumbled on a weird issue causing Apache to mysteriously crash – removing suhosin solved it all. I'm not sure if suhosin is installed by default on Debian, but it is often installed a a package dependency to some php-devel packages, so I find it wise always to check if it is present on the system and remove it if it is.

8. Enable Apache mod_deflate (gzip) compression to speed up delivery of CSS and Javascripts

Archiving with gzip and de-archiving CSS, JS and HTML is very useful, as it reduces the size of transferred content. This however might impose a bit of higher CPU load, so I only enable this one whether I target increase in network thoroughput, however for people concerned of CPU load it is better to keep it off as it is by default.

For a bit more on how mod_deflate is enabled on Debian check my previous article – Speeding Apache hosted websites with mod_deflate gzip compression

CentOS and RHEL users who need to enable mod_deflate – check here

9. Change the way logrotate handles log rotation (disable log gzip compession) or disable Apache logging completely

On Linux servers with Apache where 30000 to 50000 of unique IP visitors requests are served, the access.log becomes enormous. Things become even worser as by default Apache logs are configured to be rotated once a week instead of daily. Thus once logrotation takes place, a huge log has to be processed – for instance 20 GB. This puts extra load on the server and often makes the normal Apache operation bloated. To get rid of this problem I suggest you check my previous article – Recommended access.log logrotate practices on heavy loaded servers

Alternatively it is sometimes, better to completely disable Apache access.log logging to reduce a bit the Apache load – though from security and statistical point of view it is bad practice. I've disabled it however, as on some servers logging is implemented on PHP scripts level instead. I've earlier blogged how disabling access.log and error.log is done here

10. Disable Apache version reporting

This is more of a security than performance optimization, but also has neglectful effect, as on requests one line less is reported by Apache 🙂
To disable Apache version reporting check my previous article here

11. Switch from mpm_prefork to  mpm_worker Apache (threaded) engine

For some new Apache configurations, which doesn't need exec(); or system(); or any other PHP embedded external code execution functions, from performance point of view it is much better to just switch to the much more sophisticated performance efficient and less memory hungry Apache2  mpm-worker engine – the downside of it is you will have to configure PHP to be executed via php5-cgi apache module.

12. Tune up (increase) PHP memory_limit variable

This is not Apache optimization, but most servers need it as they run Apache and PHP in a line. Default PHP memory_limit is set to the low 16 Mb it is good to raise it to 64 or 128MB (but be careful as this might make Apache easier to DoS or DDoS)
I've blogged on the topic of memory_limit and timezone issues I experienced earlier here

13. Make sure you have a good quick DNS set in /etc/resolv.conf

An usual /etc/resolv.conf which I use for new servers with Apache looks like so:

debian:~# cat /etc/resolv.conf

The first line is set to use, as I find it very useful and to improve overall system efficiency and make it much fail proof, if the server is configured to run a custom DJBDNS server on localhost.

As you see further DNS set in my usual resolv.conf's are Google's Public DNS and and OpenDNS's and

I highly recommend you follow my practice and install DJBDNS local caching DNS to speed up resolving efficiency and hence speed up Apache client interactions (of course this is useful only if Apache or some PHP scripts use DNS requests, but as most do it is a  good practice)

After all changes, to take affect I do the usual Apache restart with;

debian:~# apache2ctl -k restart

That's it, if you know of other optimization tips, Please drop a comment 🙂

How to solve “eAccelerator requires Zend Engine API version 220060519 , the Zend Engine API version 220090626 which is installed, is newer. Contact eAccelerator at for a later version of eAccelerator.” on FreeBSD

Monday, April 4th, 2011

I’ve recently upgraded my FreeBSD Apache server from port www/apache20 I had some issues before I tune up and recompile also the php5 port but eventually it worked out, however the Eaccelerator content caching module failed to load as it was outdated.

That’s a common inconvenient with eaccelerator that every system administrator out there has faced once or twice, especially on systems that has custom compiled Apache servers and does not use a specific precompiled version of the eaccelerator.

To solve the situation as you can expect I jumped on in the /usr/ports/www/eaccelerator and removed the current installed version of eaccelerator in order to compile and install the latest port version.:
To do that I first attempted to upgrade the eaccelerator port with portmaster but as there were some problems caused by autoconf initialization etc., I finally decided to abandon the idea of using portmaster and did it manually with the good old well known trivial commands:

freebsd# cd /usr/ports/www/eaccelerator
freebsd# make deinstall
freebsd# make install && make clean

I’ve continued further and restarted my Apache server to load the new eaccelerator version and made a small phpinfo php script to test if the eaccelerator is properly loaded, yet with zero success.

After checking out in my /var/log/httpd-error.log , I’ve determined the following error:

Failed loading /usr/local/lib/php/20060613/ Cannot open "/usr/local/lib/php/20060613/"

The error is quite obvious, to solve it I’ve opened my php configuration file /usr/local/etc/php.ini and placed in it:

and substituted the line:




Further on I gave Apache another restart with:

freebsd# /usr/local/etc/rc.d/apache2 restart
Performing sanity check on apache2 configuration:
Syntax OK
Stopping apache2.
Waiting for PIDS: 71140.
Performing sanity check on apache2 configuration:
Syntax OK
Starting apache2.

followed by another test if the eaccelerator is loaded with the phpinfo(); script.

Now even though the Failed loading /usr/local/lib/php/20060613/ Cannot open “/usr/local/lib/php/20060613/” was no more, the Eaccelerator was yet not loaded.

Another consult with /var/log/httpd-error.log now revealed me another eaccelerator error you read below:

eAccelerator requires Zend Engine API version 220060519.
The Zend Engine API version 220090626 which is installed, is newer.
Contact eAccelerator at for a later version of eAccelerator.

I did about 20 minutes of investigation on the internet looking for a possible fix which gave me some idea what might be the cause for error message, though it was finally my try/fail methodology that helped me solve the issue.

The solution to the issue appeared to be easy thanks God, to solve the error all you need to do is one more make clean right before installing the eaccelerator port.:
Here are the commands necessary to issue to solve the error and make the eaccelerator load properly:

freebsd# cd /usr/ports/www/eaccelerator
freebsd# make clean &&
freebsd# make install clean

Now after restarting the Apache server once again eaccelerator has properly been loaded once again.

Howto install GeoTrust RapidSSL certificate on Debian Lenny / Squeeze / Wheezy Linux

Thursday, March 25th, 2010

I faced the task of generating official Validated SSL Certificates by in mydaily duties as a System Administrator at . Though generating self-signedSSL certificate is comparatively easy task. It was a pain in the ass setting Apache version 2.2.9-10+lenny6to correctly serve pages through https:// protocol over openssl version 0.9.8g-15+lenny6.I’ll try to go through the whole process of Generating the certificate in order to help some other Debianusers out there to face less setbacks in such a simple task as installing a Trusted SSL Certificate issued(bought) by RapidSSL. Even though this article will mostly deal with SSL certificate issued by RapidSSL,it should be not a problem to apply this methodogy with Verisign or some of the other Geotrust issuedSecure Socket Layer certificates.

In generating the Validated certficate I used enom which is a domain name,ssl certificates, email and hosting company whole-saler.
Fron emon’s website after logging in and using the web interface, there are two major things required to fill inin order to issue your Trusted SSL certificate.

1. Fill in in a form a CSR file, this is usually generated on the Linux server using the openssl.
To issue the CSR file required by Enom use the following commands:

a. First we generate an DES3 RSA encrypted key which we will use next to generate the opeensl CSR file required by ENOM.
debian:~# /usr/bin/openssl genrsa -des3 -out 2048
Enter pass phrase for

You’ll be required to fill in a pass-phrase that will be later be required to fill in before Apache servers starts or restarts,so make sure you fill something you either remember or you keep the password stored in a file.
You have to change also the in accordance with your domain name.
Now as we already have a proper generated DES3 RSA key afterwards it’s necessery to generate the CSR file with the openssl command line frontend.
So here is how:

debian:~# /usr/bin/openssl req -new -key /home/hipo/ -out /home/hipo/

Again in the above example change all the paths and file names as you wish.
It’s necessery that the end user fill in a number of questions related to the Certificate Signing Request.
Herein I’ll list what kind of prompts will emerge after executing the above command:

Enter pass phrase for /home/hipo/
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Note that you’ll hav eto fill in the pass phrase previously entered during the generation of the file.
In case if you’d like to read more thoroughly on the subject of howto create a Certificate Signing Request or (CSR) as we called it on multiple times, you can read About Certificate Signing Request (CSR) Generation Instructions – Apache SSL more in depth here

2. Hopefully following the above instructions you’ll now have a file named www.domain.csrJust open the www.domain.scr and copy paste it’s content to the ENOM website CSR * webform.

3. Further on select your Webserver type on Enom’s website:In our case we have to select Apache + ApacheSSL

4. What follows next is filling in your company contact information This is also required for proper certificate generation, you have to think twice before you fill in this data, take a note this can’t be changed later on without issuing a brand SSL new certificate.

Apart from the 3 major above requirements to fill in Enom there are some few more radio buttons to use to make some selections according to your personal preferences, however I won’t take time to dig in that and I’ll leave this to you.
After all the above is fulfilled you’ll have to submit your certificate details and choose an email address to which you will receive in a minute a RapidSSL Certificate Request Confirmation

Following a link from the email, will show you some basic information about the certificate about to be generated. That’s your final chance to cancel the issued Trusted Certificated.
If you’re absolutely sure the information about to enter the certificate is correct then you’ll have to follow a link and approve the certificate.

You’ll be informed that you’ll receive your certificate either through Certifier website (e.g. Enom’s website) or via another email.
I thought it’s more probable I receive it via email but anyways I was wrong. More thank 4 hours has passed since the certificate was issued and is available via Enom’s interface but I haven’t received nothing on my mail.
Therefore my friendly advice is to check about your brand new shiny Trusted Certificate on Emom’s website. I had mine ready in about 10 minutes after the CSR was issued.

Assuming that you’ve succesfully obtained the SSL Trusted certificate from RapidSSL what follows is setting up the certificate.
Initially I tried using documentation from RapidSSL website called Installing your SSL Certificate / Web Server Certificate / Secure Server Certificate from
I tried to configure one of my Virtualhost as shown in their example inserting in my /etc/apache/sites-available/ file, few directives within the VirtualHost something like the shown below

SSLEngine on
# cointains the Trusted SSL certificate generated and obtained by you from RapidSSL
SSLCertificateFile /etc/apache2/ssl/
# contains the file used to generate the CSR file as described earlier in this post
SSLCertificateKeyFile /etc/apache2/ssl/

It is also possible insetad of using the SSLCertificateFile and SSLCertificateKeyFile directvies directives in Apache config to use:


Another alternative is to use

SSLCertificateFile /etc/ssl/certs/your-domain-name.crt
SSLCertificateKeyFile /etc/ssl/certs/your-domain-name.key
SSLCACertificateFile /etc/ssl/certs/gd_bundle.crt

The key file is the one generated earlier on the server and handed to the SSL regisrar, the files:

your-domain-name.crt and gd_bundle.crt files are provided by RapidSSL or from whatever SSL registrater the SSL was purchased.

After trying the above configuration and restarting apache with:

/etc/init.d/apache2 restart

Apache failed to start, it might be helpful to somebody out there the error I had in my apache error.log:
The error.log red the following:

[warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)

After some 30 minutes or an hour of Googling on the error I came to the conclusion that the error is caused, becauseApache is supposed to work with .PEM files instead of the classical .CRT and .KEY files asnormally approached in most of the other Unix operating systems.

It took me a bit more of reading on the internet to find out that actually the .pem files so widely adopted in Debian simply contain both the file and the key simply pasted one after another, this I also observed from the default Apache self-signed certificate that I believe comes with debian /etc/apache2/ssl/apache.pem .
So I copied both the content of my and and store it in one file:

Also the following configuration:
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/

had to go in your

Last thing that’s left is to restart your Apache;

/etc/init.d/apache2 restart

Apache will prompt you for your certificate password entered by you during the generation. Type your password and with a bit of luck and hopefully with God’s help you’ll be having a Trusted Certificate on your webserver.

Last step is to check if the certificate is okay accessing your domain

Well this is the end of the article, hope you enjoy.If you do please leave your comments, any corrections are also welcomed 🙂