Importing gnupg key in apache

In case you need to use PGP in php you need to install gnupg extension in php. The problem comes when you want to run the routine from the webserver as the apache does not have a home and it cannot have a keyring.

For command line execution of the php script the current user key ring is used and the finger print of the key is used to identify and load the key.

In order to import key in Apache you need to set the environment variable in php script and the web server need to have access to that path. The following method is recommended.

a) Import the key in any user

b) Copy the whole .gnupg directory to apache home normally /var/www

cp -R ~/.gnupg /var/www

c) Chown to apache

chown -R apache:apache /var/www/.gnupg

This will ensure apache has a seperate set of key ring on its own.

You can also specify the home at time of import to bye pass this set

gpg –homedir /var/www –import public.asc

Now the import step is to specify in php script where to load the keys

// GnuPG code
putenv("GNUPGHOME=/var/www/.gnupg/");
Advertisements

Apache Performance Tuning: KeepAlive to remove latency

TCP protocol closes the connection on every file request and a new request is required to be created for each file. Using KeepAlive we can push more than one file in same TCP Connection.

Apache is the most widely used web server on the Internet. Knowing how to get the most out of Apache is very important for a systems administrator. Optimizing Apache is always a balancing act. It’s a case of sacrificing one resource in order to obtain savings in another.

 

What is KeepAlive?

HTTP is a session less protocol. A connection is made to transfer a single file and closed once the transfer is complete. This keeps things simple but its not very efficient.

To improve efficiency something called KeepAlive was introduced. With KeepAlive the web browser and the web server agree to reuse the same connection to transfer multiple files.

Advantages of KeepAlive

  • Improves website speed: It reduces latency associated with HTTP transfers and delivers a better user experience.
  • Reduces CPU usage: On the server side enabling KeepAlive reduces CPU usage. Consider that a typical web page has dozens of different files such as images, stylesheets, javascript files etc. If KeepAlive is disabled a separate connection must be made for each of those files. Creating and closing connections has an overhead and doing it for every single file wastes CPU time.

Disadvantages of Keepalive

  • Increases memory usage: Enabling KeepAlive  increases memory usage on the server. Apache processes have to keep connections open waiting for new requests from established connections. While they are waiting they are occupying RAM that could be used to service other clients. If you turn off KeepAlive fewer apache processes will remain active. This will lower memory usage and allow Apache to serve more users.

When should you enable KeepAlive?

Deciding whether to enable KeepAlive or not depends on a number of different factors:

  • Server resources: How much RAM vs. how much CPU power you have? RAM is often the biggest limiting factor in a webserver. If you have little RAM you should turn off KeepAlive because having Apache processes hanging around while they wait for more requests from persistent connections is a waste of precious memory. If CPU power is limited then you want KeepAlive on because it reduces CPU load.
  • Types of sites: If you have pages with a lot of images or other files linked into them, KeepAlive will improve the user experience significantly. This is because a single connection will be used to transfer multiple files.
  • Traffic patterns: The type of traffic you get. If your web traffic is spread out evenly throughout a day then you should turn on KeepAlive. OTOH, if you have bursty traffic where a lot of concurrent users access your sites during a short time period KeepAlive will cause your RAM usage to skyrocket so you should turn it off.

Configure Apache KeepAlive settings

Open up apache’s configuration file and look for the following settings. On Centos this file is called httpd.conf and is located in /etc/httpd/conf. The following settings are noteworthy:

  • KeepAlive: Switches KeepAlive on or off. Put in “KeepAlive on” to turn it on and “KeepAlive off” to turn it off.
  • MaxKeepAliveRequests: The maximum number of requests a single persistent connection will service. A number between 50 and 75 would be plenty.
  • KeepAliveTimeout: How long should the server wait for new requests from connected clients. The default is 15 seconds which is way too high. Set it to between 1 and 5 seconds to avoid having processes wasting RAM while waiting for requests.
Other settings

KeepAlive affects other settings in your Apache configuration file even though they are not directly related. Here are the settings in an Apache prefork MPM webserver:

  • MaxClients: MaxClients is the maximum number of child processes launched by Apache to service incoming requests. With KeepAlive enabled you have will have a higher number of child processes active during peak times. So your MaxClients value may have to be increased.
  • MaxRequestsPerChild: The number of requests a child process will serve before it is killed and recreated. This is done to prevent memory leaks. When KeepAlive is turned on each persistent connection will count as one request. That effectively turns MaxRequestsPerChild into a maximum connections per child value. As a result you can set a lower MaxRequestsPerChild value if you allow KeepAlive. If you don’t allow KeepAlive you should increase the MaxRequestsPerChild value to prevent excessive CPU usage.

To set keep=alive parameters in Apache2  Httpd, you need to pay attention to 3 directives:

Keep Alive

KeepAliveTimeout

MaxKeepAliveRequests

KeepAlive Directive

Description: Enables HTTP persistent connections
Syntax: KeepAlive On|Off
Default: KeepAlive On
Context: server config, virtual host
Status: Core
Module: core

The Keep-Alive extension to HTTP/1.0 and the persistent connection feature of HTTP/1.1 provide long-lived HTTP sessions which allow multiple requests to be sent over the same TCP connection. In some cases this has been shown to result in an almost 50% speedup in latency times for HTML documents with many images. To enable Keep-Alive connections, set KeepAlive On.

For HTTP/1.0 clients, Keep-Alive connections will only be used if they are specifically requested by a client. In addition, a Keep-Alive connection with an HTTP/1.0 client can only be used when the length of the content is known in advance. This implies that dynamic content such as CGI output, SSI pages, and server-generated directory listings will generally not use Keep-Alive connections to HTTP/1.0 clients. For HTTP/1.1 clients, persistent connections are the default unless otherwise specified. If the client requests it, chunked encoding will be used in order to send content of unknown length over persistent connections.

When a client uses a Keep-Alive connection it will be counted as a single “request” for the MaxRequestsPerChild directive, regardless of how many requests are sent using the connection.

KeepAliveTimeout Directive

Description: Amount of time the server will wait for subsequent requests on a persistent connection
Syntax: KeepAliveTimeout seconds
Default: KeepAliveTimeout 5
Context: server config, virtual host
Status: Core
Module: core

The number of seconds Apache will wait for a subsequent request before closing the connection. Once a request has been received, the timeout value specified by the Timeout directive applies.

Setting KeepAliveTimeout to a high value may cause performance problems in heavily loaded servers. The higher the timeout, the more server processes will be kept occupied waiting on connections with idle clients.

In a name-based virtual host context, the value of the first defined virtual host (the default host) in a set of NameVirtualHost will be used. The other values will be ignored.

MaxKeepAliveRequests Directive

Description: Number of requests allowed on a persistent connection
Syntax: MaxKeepAliveRequests number
Default: MaxKeepAliveRequests 100
Context: server config, virtual host
Status: Core
Module: core

The MaxKeepAliveRequests directive limits the number of requests allowed per connection whenKeepAlive is on. If it is set to 0, unlimited requests will be allowed. We recommend that this setting be kept to a high value for maximum server performance.

For example:

<pre><code>MaxKeepAliveRequests 500</code></pre>

Apache Performance Tuning: Use a far future expires header

Using a far future expires header

 

By using a far future expires header you can efficiently control how assets are cached on the client, which results in improved performance. Here’s how to set it up correctly with Apache, and some pointers on how to refresh users cache when you modify files.

YSlow

Most of you probably already know YSlow, the plugin created by Yahoo’s exceptional performance team. These guys have done some awesome work on performance, and therules behind YSlow (summed up in Steve Souders’ book) are a gold mine for people who wants to improve performance on their web applications. If you don’t already have it, install it now!

In their research, the exceptional performance team found that two of the most effective steps you can take to improve performance is 1) to reduce the number of HTTP requests, and 2) using a far future expires header, which is what we’re talking about today.

Benefits of a far future expires header

A far future expires header is used for content that infrequently changes. Usually, our applications static assets (ie graphics, stylesheets and scripts) are a good fit. Most of todays sites use a JavaScript library, and together with their own code they easily have 100k of JavaScript. In addition to this, there’s a few 10ks of stylesheets and probably atleast 10k of (design) graphics.

These assets only change when we modify our sites design and/or behaviour, and so it should not be necessary for our users to download these files more than once per deployment. Unfortunately, for most sites you actually download all these files on every request. By using an expires header far into the future, the browser will not download these files again before the given date. This means you can save a few hundred kb of assets on every request!

Problems with far future expires headers

The problem with the far future expires header is exactly the same as the benfit: the bowserwill not download files again if the header says they haven’t changed. Even if you roll out new versions that contain important bug fixes and improvements.

The way to solve this problem is to have filenames change when their contents change. Unfortunately this yields more work, and you should seek to find a way of automating this. I’ll get back to this towards the end of this post.

Apache and expires headers

There’s two ways of getting there with Apache. mod_expires yields the most flexible solution, but mod_headers will work too, if you cannot use mod_expires for some reason.

mod_expires

First, enable the mod_expires module. For systems using apt (Debian, Ubuntu and others) you’ll do this like follows:

# Check if module is already enabled $ ls /etc/apache2/mods-enabled | grep expires # If it wasn't $ sudo ln -s /etc/apache2/mods-available/expires.load /etc/apache2/mods-enabled/ # Restart Apache $ sudo /etc/init.d/apache2 restart

Now you can use mod_expires. There are several ways to configure a future expires header (as per the documentation), I’ll use ExpiresDefault inside a FilesMatch directive:

<FilesMatch "\.(ico|pdf|flv|jpe?g|png|gif|js|css|swf)$"> ExpiresActive On ExpiresDefault "access plus 1 year" </FilesMatch>

This configuration will cause all graphics, PDFs, CSS, JavaScript and flash movies to be sent out with an expires header one year from the date they were requested. This means clients always receive a date into the future, and instead use their cached copies instead.

If you’d like more fine grained control, you can use the ExpiresByType directive.

The FilesMatch directive matches files based on a regular expression and can be tweaked to your liking. For instance, if you’d like these settings only to apply to your design assets (and not content images) you could do this instead:

<FilesMatch "/design/.*\.(ico|pdf|flv|jpe?g|png|gif|js|css|swf)$"> ExpiresActive On ExpiresDefault "access plus 1 year" </FilesMatch>

The FilesMatch directive can go in your VirtualHost configuration.

mod_headers

If you cannot use mod_expires for some reason, you can achieve a similar effect using mod_headers. This module allows you to set arbitrary headers. Using this we can manually set an Expires header as such:

<FilesMatch "\.(ico|pdf|flv|jpe?g|png|gif|js|css|swf)$"> Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT" </FilesMatch>

This needs occasional updating. Update: As Samuli points out in the comments, you should not set an expires header more than one year into the future (according to the HTTP 1.1 RFC). This means you’ll need to tend to this solution atleast once a year, should you choose to do things this way.

Busting caches

As I mentioned, you need a mechanism for updating users cache once you start using the far future expires header. When you roll out changes to your static assets, their filenames (or atleast URLs) need to change in order to be sure everyone gets the latest and greatest.

The simplest way to update file names is to attach a query parameter to your asset URLs. This is automated by a few server side frameworks, like Rails. The timestamp of last modification date is appended to the URL to a file, resulting in something like this:/stylesheets/mystyles.css?1234567890. When something is added to a URL to avoid client side caching we sometimes refer to it as a “cache buster”.

There is a problem with the above cache buster, though. The default configuration of the popular caching proxy Squid used to make Squid not consider known URLs with changed query parameters as new URLs. Effectively, users behind a Squid proxy would not have their caches refreshed by the above cache busters.

“Hard” cache busters

I like to refer to our first shot at fixing the update problem as “soft” cache busters. I consider them soft since they require no extra configuration or work on your part, other than generating the URLs.

The hard cache buster approach requires more work, but is more robust in that it will always cause clients to regard the URLs as unique and new. Instead of appending the mtimetimestamp on the URL, we include it right inside the URL, ie: /stylesheets/mysite-cb1234567890.css.

In order for this to work we need to either change our filenames on each deploy, or be a little clever with mod_rewrite. The following RewriteRule will cause the above URL, and all others like it (ie <path>-cb<mtime>.<suffix>), to seemlessly redirect to the original files (ie &le;path>.<suffix>):

RewriteRule (.*)-cb\d+\.(.*)$ $1.$2 [L]

So there you go, a “use as is” setup for improving performance by ways of the Expiresheader:

<VirtualHost *> # Usual config <FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$"> ExpiresActive On ExpiresDefault "access plus 1 year" </FilesMatch> RewriteEngine On RewriteRule (.*)-cb\d+\.(.*)$ $1.$2 [L] </VirtualHost>

Thanks to Samuli for pointing out that the expires header should not exceed one year into the future.