On 6/17/07, Thomas den Braber <[EMAIL PROTECTED]> wrote:
The problem is with the Mysql documentation, they don't share the
performance an tuning information for free and if you look on the web I
couldn't find much either.
I've always been able to find what I wanted in the MySQL docs. It
also c
-Original Message-
From: Jonathan Vanasco <[EMAIL PROTECTED]>
>
> On Jun 16, 2007, at 11:13 AM, Perrin Harkins wrote:
>
> > 300 is nothing for MySQL. You should be able to handle a few
> thousand
> > on a machine with enough RAM.
>
> agreed. MySQL connections are cheap. Postgres o
On Jun 16, 2007, at 11:13 AM, Perrin Harkins wrote:
300 is nothing for MySQL. You should be able to handle a few thousand
on a machine with enough RAM.
agreed. MySQL connections are cheap. Postgres ones consume RAM and
kernel resources, and more than 50 sucks on a box.
If you already
On 6/16/07, Thomas den Braber <[EMAIL PROTECTED]> wrote:
I have 300 connections open ( maximum but it can happen ).
300 is nothing for MySQL. You should be able to handle a few thousand
on a machine with enough RAM.
If you run many sites not all sites use their db connection, only the
ones w
On 6/15/07, Thomas <[EMAIL PROTECTED]> wrote:
Would it make any sense to write a DBD module that uses apr_dbd as a backend?
Better performance and less memory maybe ?
Well, from what I'm reading, it only helps when you run a threaded
MPM. I don't plan to do that because of the memory problems
Hi,
I once thought about this and for e.g. MySQL this is a piece of cake in
theory because the only thing you need to do is
hack a few line of the DBD::mysql-code to get the connection pointer
from apr_dbd and not create one from scratch.
Tom
Thomas schrieb:
It wasn't intended to be. It wa
>
> how about some case-specific information about your request:
The reason why I was thinking about a bd pool was because my application,
a CMS system, runs in prefork on Linux qw(mp2 apache2.2). If I allow a
maximum of 30 forks and I host 10 sites which all have their own database
I have 30
how about some case-specific information about your request:
why exactly do you want a pool of db handles, vs additional db
connections ?
what db are you using ?
depending on your design and platform, a dbpool might not be a good
idea -- or you could be best-off with a middleware
But you read this one anyway. Does this say anything about the subject?
-
Thomas
> Onderwerp: Re: TIPool
>
> Not wanting to nitpick, but I'm going to a bit anyway...
>
> When people post to this newsgroup can they please try and come up with
> subject lines that
> It wasn't intended to be. It was going to be a pool of DBI handles,
> assuming that those could be made shareable between threads. If your
> goal is to use apr_dbd from Perl, you should probably look at writing
> a DBD:: module that uses apr_dbd as a backend.
>
> - Perrin
I just bought 'the A
Not wanting to nitpick, but I'm going to a bit anyway...
When people post to this newsgroup can they please try and come up with
subject lines that are a bit more detailed and don't just seem on first
glance to be randomly generated single words?
Normally, I see a single word with an attachme
On 6/15/07, Thomas <[EMAIL PROTECTED]> wrote:
Is this project still alive ?
I don't think anyone is currently working on it. The excitement about
using threads kind of died down after we discovered they use more
memory and are slower than the prefork model.
Will this be an Perl interface to
In the Modperl documentation I read about the great idea of DBI pool in Apache:
‘The interpreter pool is implemented in terms of a "TIPool" (Thread Item Pool),
a generic api which can be reused for other data such as database connections.
A Perl interface will be provided for
13 matches
Mail list logo
