At 02:39 PM 1/22/01 +0100, Guillaume Lémery wrote:
>Woops, I forgot to say that of course I use a connection pooling.
>Just 5 connections are pooled.
>
>> How many http connections per second are you getting?
>200
So you're having 200 simultaneous connections, AND 200 connections per
second (aka hits per second)?
Wow that's quite a high load for your system (2 cpu 400MHz x86). 5 selects
and 3 updates too!
I only managed up to about 100 hits per sec on my test phonebook search app
using FastCGI and perl with just a single LIKE selects. Benchmarked using
ab with ab -n 10000 -c 200 on a Dell Poweredge 1300 single CPU 500MHz 128MB
machine. However I didn't do any tweaking yet.
Have you tried apachebench on your app? e.g.
ab -n 10000 -c 200 "http://yourserver/UriToBannerApp"
What do you get?
Is your banner app:
http://comtrack.comclick.com/cgi-bin/aff_bandeau.cgi
>I don't handle dynamic pages, but only HTTP redirects, so I think I
>don't need cache...
>I do not use PHP or CGI because they are too slow.
>I built an Apache module. I'd like to have response in 200ms max,
>because it's an application for banners.
Actually in that case the cache might still be useful. Since you're doing
redirects they should fit nicely into almost any decent cache's buffer.
If the same url always gives the same redirect that makes things even
better - you can then tell the cache to cache and not check urls until they
are 10 minutes old (or longer).
Your webapp then talks to the cache as fast as it can.
The cache talks to the client, as slow as the client is usually.
With this often a _single_ webapp instance can handle 10 or more clients.
BTW php etc can definite respond in faster than 200ms, but nevermind.
Cheerio,
Link.