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]

Reply via email to