Hi,
Thanks to all who helped me getting OCI compiled.
I've started doing some stress testing and overall, I'm pleased with the results. I
suppose that it would be nice to have connection pooling ala-ProC, but I hear that's
on it's way.
So I'm starting up apache with like 120 servers. I hit them with 120 simultaneous
requests to a simple PHP script that opens up a persistent connection and runs a token
query. netstat -n shows that the connections are indeed persistent. Next time I hit
them with the requests, they come back FAST -- I mean like 25+ pages per second (and
lemme tell you -- the hardware is OLD). But the database is hammerred with 99% usage
while PHP/apache is sleeping with 15% usage, tops. On the other hand, apache doesn't
have to be serving up images like it normally would. There is a memory limitation on
the DB so I can't open too many persistent connections, particularly if I'm not even
using them.
Here's what I was wondering: As we all know, on your averge HTML page, you might have
10-15 images that gotta get served up with the HTML. It seems to me that my
persistent connections are worth their weight in gold while the images on the page are
cheap. It's occurred to me that I probably don't want to use the same instance of
httpd for the two: when apache gets hit, it'll only use the persistent connection
once and 15 other apache processes that are holding those connections are wasted since
they're not using those connections.
How would you approach that problem?
My first instinct is to run a second apache process on a separate port or on another
IP, that would be tuned for flatfiles. It'd mean that I'd have to code all my scripts
to tell it to look for www.somewhere.com:88/banner.gif, which is fine since this is a
new architecture.
There are other OS approaches, like Linux khttpd (i dunno - is it ready for
production?) and Squid.
Any thoughts?
Dave Thomas
Chief Software Architect
BCD Enterprises, Inc.
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
