Hiyas,
Xuekun Hu escreveu:
I've sent a message a few minutes ago, ranting about the mean
of "XXXX simultaneous users".
Here 2000 simultaneous users means 2000 connections at the same time,
not the 2000 requests/s. I estimate about 150 requests/s. Those are
all PHP dynamic requests.
Hmm, 150 requests per second are a lot of requests, if they're all
handled dynamically. Can't really say if your machine is enough to
handle that much requests. In any case, I believe you're more close to
the "150 simultaneous requests being processed at the same time" (and
2000 idle connections, using keepalive).
I would look for some kind of caching and optimization engine (zend
platform, for example). You can also try to use mod_proxy or a (reverse)
squid server, to cache those requests, if possible.
Anyway, apache is surelly not the problem in your case (and we are
starting to get offtopic on this matter). :)
In resume, if you're going to serve dynamic content (be it a PHP
script, CGI, SSI or the such), it is basically impossible to guess if
your machine able to handle that much users.
If you're only talking about static content, then, that might be
doable. Personally, I would choose a "worker" model. :)
Here I have to use "prefork" model due to thread_safe issue of PHP. I
am not sure if "worker" could be used stablely with PHP with
Apache2.2.x?
I was not aware of the fact that you have some PHP applications.
You're right to choose prefork, in this case. PHP usually links to way
too many libraries, and there is no way to guarantee that all those
libraries are thread safe.
The "worker" model is well suited for static content. Also works ok if
you use CGIs to generate dynamic content (but not for FastCGIs).
Thx, Xuekun
Regards,
Domingos.
--
Domingos Parra Novo
Coordenador de Projetos
Terra Networks Brasil S/A
Tel: +55(51)3284-4275
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
