Based on your findings that all 7 DB connections are being used, I'd revise the number of threads to 8. will give it a go this monday. Yes, it's the pool_size parameter. You can increment this value *carefully* if you see that you have more threads hanging around than DB connections, like you're seeing now. I have no idea what this will do to your relational stuff. ---that really scares me. sailing the uncharted see, and me a non swimmer! The "right thing to do" is to test this outside of production. I don't want to tell you to go ahead and muck around on a production server. But if it were *me*, I might be tempted to: --like you, i'm tempted too. i'll do backup first before anything else. furthermore, i can't get the amount of traffic to really test. - First, lower the number of threads via -t8 and see what effect that has on speed. - If that doesn't solve anything, bump up both the NUMBER_OF_THREADS and the pool_size up to 10 or 12, then do some checking, and see if you still have threads waiting for a DB. Continue doing this in increments of 2 or 4, making notes as you go. Note that if it breaks your site, I'll deny I ever gave you this advice. :-) Proceed at your own risk. ---thanks for the advice that's not given ;) , i'll report progress monday! Geez, I hope not. This is an eminently solveable problem. --i hope to solve this, and prove the greatness of OSS!