cross-posting to plug instead, since i'm not part of the cs list.
Andy Sy wrote:
>>page scripting is very cpu-bound.
>>
>>
>
>Yeah, I've seen this happen. Have you tried to see
>how much PHP accelerators like Zend, PHP Accelerator
>(www.php-accelerator.co.uk) and Alternative PHP Cache
>(forgot the URL) alleviate this situation?
>
yup. this is with phpa. our app-specific benchmark shows phpa dominating
the speed tests, with apc trailing then afterburner. zend optimizers are
way below.
>Could it be that it was the "per-second" and not "per-day" criteria
>which is what did the World Cup website in? Note that Greenspun was
>NOT writing about the World Cup site (the Zeus article says that the
>World Cup site was using free software and for all you know their back
>end may have been MySQL). I'm just speculating that what happened might
>be explained by the issues Greenspun outlined.
>
yeah, i realized that as well after i clicked on the "send button" for
my previous post. still, i would think that on low end hardware, mysql
would run circles around oracle on basic sql functions (which compose
most of our app). it's interesting to note the following: 1) pconnect vs
connect on setting up mysql connections have negligible results, 2) use
of unix domain sockets (":/var/run/mysqld.sock") vs internet domain
sockets("localhost" or any ip) is also negligible on a setup where both
the web server and the database are residing on the same machine.
php.net commentaries and other web sites however insist that pconnect is
an absolute must on oracle databases.
>If a LAMP site that can handle 200 hits/second max suddenly got
>1,000 hits/second or more, wouldn't the number of forked Apache
>processes be too much for Linux and crash it? Perhaps the World
>Cup site implementors built a site that could handle 1 million
>hits a day but would not gracefully sustain a 50,000 hit per
>second burst.
>
nope. that's why there are configurable application limits on apache.
these are very well highlighted in the nicely documented httpd.conf.
specific tokens are min and max spare servers, max clients and start
clients. those planning to deploy a non-trivial web app should do well
to find their maximum hits per second and maximum concurrent hits. this
could only be done through a good app-specific testing procedure.
>I know the VM system in FreeBSD can handle this sort of overload
>and still be operational (Personally seen it, though of course it
>became as slow as molasses) and the 2.4 Linux kernels are supposed
>to match this kind of robustness but is that a reality?
>
yes it is. i've also seen what a big difference the post-2.4.10 kernels
make on system stability. they just plainly behave, and still allow you
to do logins and diagnostics even under heavy stress. i'm talking about
prolonged 0% idle cpu states here, where the pre-2.4.10 kernels just
plain hung up on us. our setup is an RH7.2 stock kernel(2.4.7-9) versus
2.4.18 straight out of kernel.org.
interesting to note that under freebsd 4.5, our application lagged
behind linux by around 10 tps, using the same hardware and
apache-php-phpa versions. we were using a dual p3-1.2, with 2GB of RAM.
>In theory, a threaded web server like AOLServer would be able to
>serve much more connections before the server starts thrashing due
>to lack of physical memory.
>
>
of course. ibm developer works articles say that thread creation speeds
are way beyond process creation (>10,000 versus between 300 to 350 per
second on a 648MHz P3). one of reasons is the simple fact that thread
creation consumes less overhead(no process id, not true for linux
though, minimal stack, shared protection space), but you already know
that. :)
i'm actually very excited when phpa starts supporting apache2. i wonder
how it's new multi-threaded setup would fare in comparison. we tried it
using our setup, but without the php accelerator and it gave us less
than 30 tps for apache 1.3.x with phpa. not bad at all.
i'll try aolserver on for size, though i heard that they have problems
integrating php with it since php is not threaded. we'll see.
--vince.
_
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
To subscribe to the Linux Newbies' List: send "subscribe" in the body to
[EMAIL PROTECTED]
