[ic] question on mod_interchange socket closing (different from previous question)

Jeff Dafoe interchange-users@icdevgroup.org
Sat Nov 2 20:26:01 2002


> Mod_interchange would have to pre-allocate a large buffer in order to
> receive the body text.  Unfortunately, there's no way of knowing how
> large to make this buffer;  The server could be sending a 20k HTML file
> or could be sending a monster 700MB CD image.

    This gets kind of crazy.. but.. read the first X bytes from IC, with X
ideally being a configurable value.  If the entire response comes in those X
bytes, close the IC socket.  Send the X bytes to the client.  If that was
not the entire response, use ap_send_fb to connect the client to the IC
stream.

> I think that, as long as Interchange is reserved for HTML/text content
> and the pages are reasonably small, there's no need to buffer the body.

    This is true, but in the theoretical case where a site is getting crazy
traffic levels, 100+ concurrent connections, it becomes more important to
free up the larger "app server" processes quicker.  With modperl, this is
typically done by putting a proxy in front of the modperl server, so the
modperl processes are quickly freed up and the proxy spools the data to the
clients.  IC

> For best performance, I recommend that Interchange runs in PreFork (RPC)
> mode and sufficient servers are spawned to handle the expected demand.

    This works up to a certain point but I think that this point can be
increased.  Particularly if the MaxRequestsPerChild is set to more than a
handful of requests, the IC processes can really start to eat memory, so it
is optimal for each IC process to be able to complete a transaction
(connect/rx/tx/disconnect) as fast as possible.  Proxying the request would
also help to make the IC/modIC combo resistant to the type of DoS attack
where a client connects, issues a request, and then receives the data at a
ridiculously slow rate.

> If you run tests and come up with comparison
> benchmarks for mod_interchange, mod_perl, vlink and tlink, I'd be
> interested to see those too.

    Depending on your thoughts, I may make the modification I am suggesting.
I will also make a script that tests the total concurrency possible with the
different interface methods.  Apache's "ab" benchmark util just grabs the
data as fast as it can, so it doesn't offer a very realistic load test from
that perspective.

    I worked with a company that developed a streaming media content
management system that is in use by a couple of large Latin American media
companies.  The system was written in modperl.  Unfortunately, the situation
that warrants the use of modperl, which is high traffic, also becomes a huge
issue under modperl.  We encountered the situation I am describing, where we
had to put a proxy in front of the modperl server to offload the spooling of
data to the client, because we were getting that much traffic.  Seeing the
mod_interchange / interchange daemon combo is fascinating, because it is
right on the verge of offering out-of-the-box proxying (and its much easier
to set up than Squid!) and the combo could easily be the perfect design
model for high traffic web applications.


Thanks for your time,
Jeff