Databases Reference
In-Depth Information
includes (ESI; see
http://www.esi.org
) to embed the small dynamic portion of the
page into the cached static portion.
• Set an expiration policy on both dynamic and static content. You can use caching
proxies such as Squid to invalidate content explicitly. Wikipedia uses this techni-
que to remove articles from caches when they change.
• Sometimes you might need to change the application so that you can use longer
expiration times. For example, if you tell the browser to cache CSS and JavaScript
files forever and then release a change to the site's HTML, the pages might render
badly. You can version the files explicitly with a unique filename for each revision.
For example, you can customize your website publishing script to copy the CSS
files to
/css/123_frontpage.css
, where
123
is the Subversion revision number. You
can do the same thing for image filenames—never reuse a filename, and your pages
will never break when you upgrade them, no matter how long the browser caches
them.
• Don't let Apache spoon-feed the client. It's not just slow; it also makes denial-of-
service attacks easy. Hardware load balancers typically do buffering, so Apache
can finish quickly and the load balancer can spoon-feed the client from the buffer.
You can also use Nginx, Squid, or Apache in event-driven mode in front of the
application.
• Enable
gzip
compression. It's very cheap for modern CPUs, and it saves a lot of
traffic. If you want to save on CPU cycles, you can cache and serve the compressed
version of the page with a lightweight server such as Nginx.
• Don't configure Apache with a Keep-Alive for long-distance connections, because
that will keep fat Apache processes alive for a long time. Instead, let a server-side
proxy handle the Keep-Alive, and shield Apache from the client. It's OK to con-
figure the connections between the proxy and Apache with a Keep-Alive, because
the proxy will use only a few connections to fetch data from Apache.
Figure 14-1
illustrates the difference.
These tactics should keep Apache processes short-lived, so you don't end up with more
processes than you need. However, some operations might still cause an Apache pro-
cess to stay alive for a long time and consume a lot of resources. An example is a query
to an external resource that has high latency, such as a remote web service. This problem
is often unsolvable.
Finding the Optimal Concurrency
Every web server has an
optimal concurrency
—that is, an optimal number of concurrent
connections that will result in requests being processed as quickly as possible, without
overloading your systems. This is the maximum system capacity we referred to in
Chapter 11
. A little measurement and modeling, or simply trial and error, can be re-
quired to find this “magic number,” but it's worth the effort.
