Category: Scalability

The cost of each tier in a web application increases as you move from URL to SQL. From the white paper:

“In the first tier—the Web tier—the cost of serving static content by use of commodity boxes running Apache is very low and, due to its stateless nature, very predictable.

• In the second tier—the J2EE tier—the cost of hardware may be the same, but both the infrastructure software and the custom application logic are significantly more expensive.

The result is predictable: Applications that tend to allow each request to get past the first or second tier will be much more expensive to scale, and applications that rely on data access from the database for each request will encounter severe limits on their scalable performance.

The lesson learned is this: handle the incoming load in the earliest-possible tier, and do it with resources that have predictable scale-out behavior and costs. For most applications, those are the resources represented by commodity hardware—servers with fast CPUs and plenty of memory.

Also, you should deliberately build an architecture that will bottleneck in the earliest-possible tier on either the CPU or in memory. Why? You’re going to have a bottleneck, whether you choose to or not. And if you don’t pick the bottleneck deliberately, it’s going to end up in the most expensive and difficult-to-scale part of your environment.”

“When building a big web application you layer caches on caches. Ideally the top cache (browser local cache) can service the entire request such as it happens on google.com. if that fails the next best thing is blazingly fast memcached. Failing that we have to aquire and compute some data which is hopefully cached. If that fails the database gets the data from its cache or from disk. If that fails than the database files are probably cached by the operating system. And finally we move the physical read head of the disk to fetch the database off permanent storage.”

I found this excellent listing of Cache-Control definitions on askapache.com:

Cache-Control: no-store
This object may not be stored in any cache, even the requestor’s browser cache.

Cache-Control: no-cache
This object may be held in any cache but it must be revalidated every time it is requested.

Cache-Control: private
This object can be stored in the requesting browser´s cache but not in a shared cache …

Cache-Control: must-revalidate
Tells caches that they must obey any freshness information you give them about an object. The HTTP allows caches to take liberties with the freshness of objects; by specifying this header, you’re telling the cache that you want it to strictly follow your rules.

Cache-Control: proxy-revalidate
Similar to must-revalidate, except that it only applies to proxy caches.

The first time a browser requests a file, an HTTP code of 200 (request for document) will be written to the web server log. It will look like this:
30.35.127.106 – – [21/Oct/2006:14:38:23 -0700] “GET /OA_MEDIA/FNDREDPT.gif HTTP/1.1” 200 70

The next time the request is received from the browser, it should be served by the browser cache. Thus the entry in the web server log file will be an HTTP code 304 (request for time stamp). It will look like this:

130.35.127.106 – – [21/Oct/2006:14:41:03 -0700] “GET /OA_MEDIA/appslogo.gif HTTP/1.1” 304

Have you changed the firmware on your Linksys router to dd-wrt? If you did, you can make a simple configuration change to the dnsmasq service that provides DNS and DHCP services. Login to the router, and browse to the Administration/Services tab, and add the following entry:

This tells the DNSMasq service to cache 2000 DNS entries. The result is that any DNS request (one is made for EVERY website request) will be served up by the local Linksys router, rather than obtaining the request from a DNS server on the Internet.

By caching DNS requests locally, you will see faster browser response times. While this DNS lookup time savings may only be milliseconds, for sites you visit multiple times in a session you will see a large boost in performance. Such sites will feel more responsive.

Here is an example of a Linux server (also behind the Linksys router) performing “dig” lookup against Google:

# dig www.google.com | grep “Query time”
Query time: 16 msec

# dig www.google.com | grep “Query time”
Query time: 1 msec

For the first request, google.com’s details were not in the Linksys cache, and the query took 16ms. The second time, the cache speeds up the lookup, and the time is reduced to 1ms.

If you login via SSH to the Linksys router and send a sigusr1 to the DNSMasq service, you can obtain a listing of the entries it is caching:
# killall -sigusr1 dnsmasq
dnsmasq: time 259374, cache size 2000, 0/16 cache insertions re-used unexpired cache entries.
dnsmasq: Host Address Flags Expires
dnsmasq: del.icio.us 206.190.56.150 4F 31
dnsmasq: www.boingboing.net 204.11.50.136 4F 281
dnsmasq: bloglines.com 65.214.39.152 4F 4294967282
dnsmasq: WRT54G 192.168.1.1 4FRI H 0
dnsmasq: pageflakes.com 69.5.89.127 4F 501127
dnsmasq: www.bloglines.com bloglines.com CF 633
dnsmasq: feeds.feedburner.com 66.150.96.111 4F 42

Loadrunner (and other monitoring tools) needs the rstat daemon to extract data from the kernel. Installing this daemon is a bit tricky, as it is part of a larger package. Here’s how you do it:

# up2date -i rusers-server

To start the daemon: # service rstatd start

NOTE: Ensure the portmap service is running first.

A server is always executing interrupts; giving attention to whatever needs it. These are so-called maskable interrupts. The CPU can mask, or temporarily ignore, any interrupt if it needs to in order to finish something else that it is doing. There are also non-maskable interrupts (NMI), which are used for serious conditions that demand the processor’s immediate attention.

When an NMI signal is received, the processor immediately drops whatever it was doing and attends to it. The NMI cannot be ignored by the server. The NMI signal is normally used for critical problem situations, such as serious hardware errors. The most common use of NMI is to signal a parity error from the memory subsystem.

Requests processed per time unit.