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]
