As mod_backhand is a web clustering tool, it should imply high
performance. One of the many goals of mod_backhand is balancing
assistance in environments where high performance is necessary. There
are many considerations to make when designing a high performance
cluster and mod_backhand will not compensate for poor network topology
and poor site design in most cases. mod_backhand is designed to
assist in serving your web site using as few resources as possible
(using your resource as efficiently as possible).
Statistics transmission and collection can suffer under high load:
The mod_backhand module forks of a daemon that manages collection and
transmission of statistics as well as pooled connections to other servers
within the cluster. If your machine is highly loaded, this process will not
be scheduled often enough and there will be a performance impact. A decent
solutions to this is increasing the priority of that daemon. The PID is in
the error_log and it will be the process that racks up a serious amount of
processor time. Just renice it to -20 or set it to real time priority if your
OS supports that.
mod_backhand is a proxy... let your OS help:
mod_bakchand, by default, uses application level proxying to do its dirty
work. This means it reads data from another server and writes it back to the
client. If the client is slow (over a modem or bad network connection) then
the mod_bakchand Apache child stands to spend time doing nothing but waiting
for the client to read all of the data.
On Unix machines with BSD compatible sochets, you are allowed to ask the kernel
to change its socket buffer size. By default, it is usually around 4 kilobytes.
This means that you can only write 4k before you are blocked waiting for the
client at the other end to consume the information. Using the default Apache
SendBufferSize directive, you can augment the buffer size to be something
larger. If you averge document is 20 kilobytes, you should probably set this
parameter up to 32k (32768). this will give you enough "room" to write the
headers and the content back to the user and allows the kernel to feed it to
the client.
mod_backhand can use a lot of files and open many file descriptors:
mod_backhand opens a file for every Apache child plus a handful at start up.
It also needs a file descriptor for each pooled connection to another server.
You need to make sure you don't overrun any preset limitations by your kernel
or shell.
Under Linux, here are a few helpful optimizations:
# echo 32768 > /proc/sys/fs/file-max
# echo 65536 > /proc/sys/fs/inode-max
If you still have errors pertaining to a file descriptor shortage, you may
need to recompile the kernel with NR_OPEN doubled.
Under Solaris:
Add:
set rlim_fd_cur=2048
set rlim_fd_max=4096
to your /etc/system and reboot.
TCP/IP and the "Keep-Alive" blessing:
Establishing a TCP/IP connection to another machine is an operation
that requires a substantial amount of work. People take this for
granted because on most systems, TCP/IP sessions initiation happens at
most a few time per second.
On a extremely busy cluster, you can expect to thousands of TCP/IP
sessions built up and torn down every second. The processing time
required of the kernel is tolling. The HTTP protocol allows a client
to make a request in a fashion so as to not tear down the TCP/IP
session. This will allow a client to establish a TCP/IP session to
the server make many serialized requests.
Most web sites that use databases and push high volumes of traffic
turn this feature off, because it has some bad side effects. The
sessions current being managed by your cluster are no longer the
length of a request plus response.
Let us assume a request takes and average of 10ms to turn around. If
you serve 1000 requests in one second and on average a client is
allowed to keep the session alive for 15 seconds without making a
request, then you are no managing 15000 open sessions at any given
moment instead of 100. This is a serious problem.
On the other hand, mod_backhand proxies requests to your other
servers. You know that it will be making many requests and you
obviously don't want to pay the overhead of building and tearing down
TCP/IP sessions for each request that is backhanded.
You need to enable "Keep-Alive" functionality within the cluster
regardless of whether or not it is enabled for the typical client.
How do you do this in Apache? Unfortunately, as of Apache v1.3.9, you
can't. But sense this can boost performance tremendously, we have a
patch to the Apache source tree that will allow you to serve requests
in this fashion. (And it is only a difference of two lines).
Here is the patch
file and since it is so small, here it is complete:
*** http_protocol.c Sat Aug 14 05:21:19 1999
--- http_protocol.c.new Sat Jan 29 19:04:04 2000
***************
*** 303,309 ****
"chunked") ||
((r->proto_num >= HTTP_VERSION(1,1)) &&
(r->chunked = 1))) && /* THIS CODE IS CORRECT, see comment above. */
! r->server->keep_alive &&
(r->server->keep_alive_timeout > 0) &&
((r->server->keep_alive_max == 0) ||
(r->server->keep_alive_max > r->connection->keepalives)) &&
--- 303,310 ----
"chunked") ||
((r->proto_num >= HTTP_VERSION(1,1)) &&
(r->chunked = 1))) && /* THIS CODE IS CORRECT, see comment above. */
! (r->server->keep_alive ||
! ap_table_get(r->headers_in, "BackhandProxied")) &&
(r->server->keep_alive_timeout > 0) &&
((r->server->keep_alive_max == 0) ||
(r->server->keep_alive_max > r->connection->keepalives)) &&
If you are currently using mod_backhand in a set up that has
KeepAlives Off in the Apache configuration, this should remove
thousands of TCP/IP connections per second for the overall operation.
This could lead to a significant performance boost if your current
bottleneck is related to kernel networking.
|
