On Aug 18, 2005, at 5:55 PM, David Hodgkinson wrote:
But you're still trying to optimise prematurely.
I'll need to to a lot of optimizing in the future - but I just want to
avoid as many obvious mistakes as possible and compartmentalize where
the mistakes are made so I can find them qui
On 18 Aug 2005, at 18:58, Jonathan Vanasco wrote:
i'm thinking about moving to pgsql for stored procedures too (yes
my5 has it, but its beta), but thats an entirely OT discussion.
And you have pgpool too.
But you're still trying to optimise prematurely.
Treat your fat apaches as application
On Aug 18, 2005, at 1:42 PM, Perrin Harkins wrote:
If you can figure out a way to do
that, you could theoretically have a separate process managing a pool
of
them. I doubt it would be worth it though.
That's pretty much what I was thinking, but I didn't really want to do
this in a situat
On Thu, 2005-08-18 at 13:31 -0400, Jonathan Vanasco wrote:
> I didn't see anything about DBI connections in the guide about that.
It's one of the primary reasons to use a front-end server.
I'm afraid your idea won't work because most databases don't support
passing handles across processes. If y
I'm front-ending with lighttpd right now (originally was apache, but I
moved over) and limiting with maxclients
I didn't see anything about DBI connections in the guide about that.
i guess i was just thinking about making myself more aware of the
number of connections.
On Aug 18, 2005, at 1
On 18 Aug 2005, at 18:18, Jonathan Vanasco wrote:
Instead of connecting to the DB and having DBI cache the handle
after-the-fork, would it make sense to subclass Apache::DBI, have
the parent process create a defined number of connections, and then
use some sort of roundrobin/checkout to si
Instead of connecting to the DB and having DBI cache the handle
after-the-fork, would it make sense to subclass Apache::DBI, have the
parent process create a defined number of connections, and then use
some sort of roundrobin/checkout to sign out a handle during a request?
You're asking "why?"
