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

["Kevin Walsh" <suppressed>]

Jeff Dafoe suppressed wrote:
> >
> > 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.
> 
The trouble is that you will not know that you have the entire response
until you read zero bytes on a request.  If you ask for 8k and receive
8k there may be more to come.  Also, if you ask for 8k and receive 4k
then there may be more to come.

> >
> > 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
>
I know what you mean.  I'm just having trouble thinking of a way to do
it.  Perhaps if Interchange set the Content-Length header then that'd
make life a little easier.  I'll think about it.

> >
> > 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 don't know what sort of test environment you are able to set up,
but perhaps a 9600bps serial PPP link from the test client will do
the trick.

> 
> 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.
> 
Well, that's the idea.  Mod_interchange also has failover support for
clustered environments, allowing Interchange to be taken offline on one
machine while still allowing mod_interchange, on the same machine, to
process requests via another machine.  It's not a lot of use, except if
Interchange fails for some reason, but it's a start.

-- 
   _/   _/  _/_/_/_/  _/    _/  _/_/_/  _/    _/
  _/_/_/   _/_/      _/    _/    _/    _/_/  _/   K e v i n   W a l s h
 _/ _/    _/          _/ _/     _/    _/  _/_/    suppressed
_/   _/  _/_/_/_/      _/    _/_/_/  _/    _/

_______________________________________________
interchange-users mailing list
suppressed
http://www.icdevgroup.org/mailman/listinfo/interchange-users