PHP/OCI8 design for persistent connection tuning
| From: | Dave Thomas | Date: | Tue, 17 Apr 2001 20:27:29 +0000 |
| Subject: | PHP/OCI8 design for persistent connection tuning | ||
| Groups: | php.db php.general php.general | ||
| Request: | Send a blank email to php-general+get-49042@lists.php.net to get a copy of this message | ||
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.