[Sorry if this is a duplicate, but I believe the first message
did not get through]
Hi all,
I am working in an Apache2/mod_perl2 environment, with MySQL DBs, and
I have a somewhat special need with respect to persistent connections;
I need some of the database connections to be persistent
After looking at the documentation/code I do not think I can use
Apache::DBI for that (but I'd love to be proven wrong!). Can anybody
point me towards a solution. I can obviously copy and modify
Apache::DBI, but it seems the kind of code that it's easy to get wrong
in very subtle ways, so
On 4/16/07, Kelvin Wu [EMAIL PROTECTED] wrote:
but noticed sometimes cpu usage goes up to 30, and there are 80 httpd...
can't even log into mysql because 'too many connections', have to restart
apache and mysql.
Have you set MaxClients on your mod_perl server to something that
won't cause your
have been running mod_perl 2 with apache::dbi for few days, so far so good,
normally 20 httpd with 30-40 persistant connections, cpu usage is under 1.
but noticed sometimes cpu usage goes up to 30, and there are 80 httpd...
can't even log into mysql because 'too many connections', have
Larry Leszczynski wrote:
On Wed, 29 Nov 2006, Michael Peters wrote:
Maybe you could have Apache::DBI issue a warning if it's being loaded
and DBI has already been loaded. Something as simple as the attached
patch should work.
+# we can only do our magic if DBI isn't already loaded
On Nov 28, 2006, at 11:03 PM, Philip M. Gollucci wrote:
is this mod_perl 1 or 2 ?
Setting $Apache::DBI::Debug = 2; and watching you're error log file
should tell you what its doing.
package X;
# database
our $host = 'mysql.x.y';
our $dsn = dbi:mysql:db;host=$host;
our $user = 'u';
our $pass
Lev Lvovsky wrote:
On Nov 28, 2006, at 11:03 PM, Philip M. Gollucci wrote:
is this mod_perl 1 or 2 ?
Setting $Apache::DBI::Debug = 2; and watching you're error log file
should tell you what its doing.
package X;
# database
our $host = 'mysql.x.y';
our $dsn = dbi:mysql:db;host=$host;
our
Philip M. Gollucci wrote:
If you can suggest a documentation patch you feel clarify things, I'll
read it over and commit for version 1.06 (sorry about that 1.05 is current)
Maybe you could have Apache::DBI issue a warning if it's being loaded and DBI
has already been loaded. Something as
Michael Peters wrote:
--- DBI.pm.old 2006-11-29 14:30:56.0 -0500
+++ DBI.pm 2006-11-29 14:32:05.0 -0500
@@ -15,6 +15,10 @@
$modperl::VERSION 1.99) {
require Apache;
}
+
+# we can only do our magic if DBI isn't already loaded
+warn
Keep it on list -- others have the same question 'trust me'
Lev Lvovsky wrote:
Philip, not sure if this is possible, but what happens if Apache::DBI is
loaded in the correct order the first time, but then afterwards loaded
again after DBI has been loaded - does the Perl loader make sure this
On Nov 29, 2006, at 2:46 PM, Philip M. Gollucci wrote:
Michael Peters wrote:
+# we can only do our magic if DBI isn't already loaded
+warn Apache::DBI must be loaded after DBI to work correctly;
I like it -- any objects list ?
i REALLY like that idea.
it solves the problem AND
On Wed, 29 Nov 2006, Michael Peters wrote:
Maybe you could have Apache::DBI issue a warning if it's being loaded
and DBI has already been loaded. Something as simple as the attached
patch should work.
+# we can only do our magic if DBI isn't already loaded
+warn Apache::DBI must be
It looks like from reading the docs, that the startup.pl file can
handle specifying more than one user for the purpose of making
multiple connections with different database accounts.
I'm having a problem in retrieving these cached connections when
running the code after server startup
Lev Lvovsky wrote:
It looks like from reading the docs, that the startup.pl file can handle
specifying more than one user for the purpose of making multiple
connections with different database accounts.
I'm having a problem in retrieving these cached connections when running
the code after
On Sat, 2006-08-05 at 18:46 -0500, Mark Stosberg wrote:
So are you suggesting I should use:
$dbh-prepare_cached($sql, { pg_server_prepare = 1 }, 3)
...throughout the web-app?
If you use prepare_cached, adding the 3 is the safest way to go. It
avoids possible problems with accidentally
looked at the DBD::Pg code myself, but my C skills
aren't up to digging into the XS code there.
I found a related mention of this issue here:
http://fudforum.org/forum/index.php?t=msgth=4598start=0;
There the fix involved putting using DEALLOCATE when persistent
connections are detected. The actual
it,
then deallocating it immediately afterwards. thats some brilliant
php right there. why didn't they just do a conditional to never
prepare on persistant connections ?
before looking into how dbd::pg is internally handling the prepared
statements, are you using some sort of db abstraction layer like
Mark Stosberg wrote:
Hello,
I'm wondering if some other people here have some wisdom about this case
a few people have run into, apparently with no resolution.
Newer versions of DBD::Pg and PostgreSQL support a feature called
server side prepares, which is supposed to give a significant
David Dick wrote:
Mark Stosberg wrote:
Hello,
I'm wondering if some other people here have some wisdom about this
case a few people have run into, apparently with no resolution.
Newer versions of DBD::Pg and PostgreSQL support a feature called
server side prepares, which is supposed
On Sat, 2006-08-05 at 09:02 -0500, Mark Stosberg wrote:
However, when deploying it on mod_perl on a busy website, I quickly saw
a lot of this kind of error:
prepared statement dbdpg_7 already exists
Do you use prepare_cached? You might want to try that, with a 3 for the
$if_active
of this kind of error:
prepared statement dbdpg_7 already exists
Server-side prepare statements exists on a per-connection basis, and
have been causing some problems for applications that do funky things
with connections, such as pgpool. However, when mod_perl is involved,
the problem is usually
Perrin Harkins wrote:
On Sat, 2006-08-05 at 09:02 -0500, Mark Stosberg wrote:
However, when deploying it on mod_perl on a busy website, I quickly saw
a lot of this kind of error:
prepared statement dbdpg_7 already exists
Do you use prepare_cached? You might want to try that, with a 3 for
, running it,
then deallocating it immediately afterwards. thats some brilliant php
right there. why didn't they just do a conditional to never prepare on
persistent connections ?
Or as they say at http://www.thedailywtf.com/, brillant.
before looking into how dbd::pg is internally handling
I am using Apache/mod_perl/ApacheDBI/DBI combination with connect_on_init()
to provide child processes (prefork model) with connections had had been
already established.
On database backend, I currently see 77 connections established.
netstat on the front end indicates 77 active connections
On Fri, 2006-01-13 at 12:11 -0500, [EMAIL PROTECTED] wrote:
On database backend, I currently see 77 connections established.
netstat on the front end indicates 77 active connections.
However, Apache2::Status always displays 2 connection.
Am I missing something?
That means you have two
On 12/24/05, Bob Ippolito [EMAIL PROTECTED] wrote:
I don't think any of this is really relevant to mod_perl though, it's bound
to the way Apache works.
But if a mod_perl-compatible environment were constructed that did not depend
on apache, would that be on-topic for this list?
Happy new year
On Dec 21, 2005, at 1:26 PM, Jonathan wrote:On Dec 21, 2005, at 12:23 PM, Perrin Harkins wrote: On Tue, 2005-12-20 at 14:42 -0800, Ken Simpson wrote: Alas, if only the Perl interpreter was truly thread safe and did notclone a new interpreter for each thread, we could just usethreads... Those
, but it is not releasable
and not directly applicable to rejiggering singlethreaded into a better
more scalable mod_perl.
So here's the three tier asynchronous model (3TAM):
Main Select Loop
handles all connections from remote clients, including
relaying data from worker processes. Very
On Thu, 2005-12-22 at 12:22 -0600, David Nicol wrote:
To make a 3TAM system work like mod_perl, never mind the hooks
into the various apache request service stages, every long-running
perl script could be interpreted into one of serveral mp_like interpreters
at the handler layer, or even every
On Dec 22, 2005, at 1:51 PM, Perrin Harkins wrote:
You're pretty much describing lighthttpd + FastCGI. However, I don't
think it supports SSL and it obviously has no support for any other
apache modules or for hooking into request stages (although FastCGI
has
some things, like
life as a mod_perl
app, but forks a tiny Event::Lib based pure-Perl app after
configuration to handle all the slow connections. A pool of mp2
processes is kept around, running a very simple protocol handler to
receive and process short running but CPU-intensive requests from the
IO subsystem.
The nice
On Tue, 2005-12-20 at 14:42 -0800, Ken Simpson wrote:
Alas, if only the Perl interpreter was truly thread safe and did not
clone a new interpreter for each thread, we could just use
threads... Those Python people have it good in some ways.
Not that good really. As I understand it, the Python
On Tue, 20 Dec 2005 14:42:12 -0800, Ken Simpson [EMAIL PROTECTED] said:
[note: Subject changed from go crazy with me -- LoL]
I'd also like to hear what people are doing when the apache model has
scaling problems. We have one problematic project here: we're a
gateway and must server a
, but in the end I wrote a bit of Erlang to proxy
to the backend server (it was the first serious Erlang I had written,
and it was surprisingly easy to do). It has worked well for us, and the
ratio of peak connections to revenue (and thus hardware budget) on this
system is pretty off-kilter. Not for everyone
Hi all.
My project is built on Apache+mod_perl2 + PostgreSQL, so I use DBI::Pg
to connect to database and Apache::DBI for connection reuse. My DBI
connections are initialized at ChildInit phase. I examined Apache::DBI
sources and found that it creates one connection per dsn (am i right
On Fri, 2005-11-04 at 17:43 +0200, Taras Yurij Vasylovitch wrote:
I've tried to write my own db connections factory but I found
out that DBI connections cannot be shared between threads because they
are objects.
This could be changed, but it would require some work. Hardly anyone
actually
server, we saw
a number or errors that that the number of max connections had been
exceeded.
Not surprisingly, this resulted in user visible errors on the web server.
I'm curious: What is the expected behavior from Apache::DBI in this
case? Would it quickly give up and move on, or perhaps
On Wed, 2005-07-06 at 18:11 +, Mark Stosberg wrote:
On the front end web server machine, the CPU spiked up well beyond
average and stayed there. On the backend PostgreSQL 7.4 server, we saw
a number or errors that that the number of max connections had been
exceeded.
The CPU spike sounds
, 2005-07-06 at 18:11 +, Mark Stosberg wrote:
On the front end web server machine, the CPU spiked up well beyond
average and stayed there. On the backend PostgreSQL 7.4 server, we saw
a number or errors that that the number of max connections had been
exceeded.
The CPU spike sounds a bit
to meet. I did want to talk with
you and the rest of the CGI::Application gang, but didn't quite have
time at this one. Maybe at OSCON, if you're going.
Thanks for the suggestion. I see we had it at 250, while our other front
end server had 180. The database server has a maximum of 400
connections
I have the following info in my startup file --
Apache::DBI-connect_on_init(DBI:mysql:database=mmg;host=HOST,user,pass);
-- That worked perfect in mod_perl1, now that I'm using mod_perl2 I get
the following info in my error log when starting apache --
[Mon Apr 25 17:45:50 2005] startup.perl:
Pratik wrote:
Hi Everyone !
Currently, I am implementing a mechanism to restrict the number of
parallel connections to the server from a single client/user.
snip
Sounds like you want to disable HTTP Pipelining, am I mistaken? If not,
Apache already has a mechanism for this, look in the default
On Mon, 07 Feb 2005 06:56:44 -0600, Joseph A Nagy Jr [EMAIL PROTECTED] wrote:
Sounds like you want to disable HTTP Pipelining, am I mistaken? If not,
Apache already has a mechanism for this, look in the default httpd.conf
firle 1.3x and 2.x for more info.
Nop. I am not looking to disable HTTP
On Sun, 2005-02-06 at 23:28 -0800, Pratik wrote:
-It does all important operations inside PerlLogHandler.
-For my requirements - where the request is serving large files for
download - I will need to move those operations in higher level
handlers - Like PerlAccessHandler or PerlInitHandler.
demonstrates:
http://www.stonehenge.com/merlyn/LinuxMag/col17.html
He is using it to throttle by CPU, but it's easy to make it use number
of connections within a time window instead.
- Perrin
[ Please keep conversation on the list. ]
Pratik wrote:
He is using it to throttle by CPU, but it's easy to make it use number
of connections within a time window instead.
But I am more interested in restricting parallel connections rather
than request/rate.
You can store simple +1/-1 values
On Sun, 06 Feb 2005 16:40:57 -0500, Perrin Harkins [EMAIL PROTECTED] wrote:
[ Please keep conversation on the list. ]
Oops...sorry for the goof-up. Can't help it :D
You can store simple +1/-1 values if you want to. The interesting part
is that it packs the data into a small fixed-size chunk
About Stonehenge::Throttle:
-It does all important operations inside PerlLogHandler.
-For my requirements - where the request is serving large files for
download - I will need to move those operations in higher level
handlers - Like PerlAccessHandler or PerlInitHandler.
-In which case, I'd be
Perrin Harkins wrote:
J Robert Ray wrote:
What I want from connection pooling is to cache database connections
for a relatively short period of time, such as while a user is
actively clicking around a web application. Once that user leaves the
application, ideally the database connections
On Fri, 2004-08-27 at 13:28, J Robert Ray wrote:
That's an excellent point, but we currently can't take that approach.
Not every app is as well behaved has Apache::DBI. ;)
They all can be if you just s/DBI-connect/DBI-connect_cached/g;
And really, what app needs to hold a live but unused DBI
This patch changes the behavior of Apache::DBI so that it no longer
holds onto connections for as long as the httpd child lives.
Brief background: I am working to keep the total connection count to our
database as low as possible. Apache::DBI tends to accumulate database
connections over time
J Robert Ray wrote:
What I want from connection pooling is to cache database connections for
a relatively short period of time, such as while a user is actively
clicking around a web application. Once that user leaves the
application, ideally the database connections would expire.
You might
On Fri, 13 Aug 2004 22:48:30 -0400, John Siracusa wrote:
On 8/13/04 5:43 PM, Perrin Harkins wrote:
This patch should make Apache::DBI work with subclassed DBI
connections. The only downside is that it makes ALL of your cached
connections subclassed if you give it one that is subclassed
This patch should make Apache::DBI work with subclassed DBI
connections. The only downside is that it makes ALL of your cached
connections subclassed if you give it one that is subclassed. Given how
most people use DBI subclasses (for universal functionality on all DBI
connections
On 8/13/04 5:43 PM, Perrin Harkins wrote:
This patch should make Apache::DBI work with subclassed DBI
connections. The only downside is that it makes ALL of your cached
connections subclassed if you give it one that is subclassed. Given how
most people use DBI subclasses (for universal
Thanks a lot Perrin, i will follow your recomendations... i've used the global
variable for the database handler for simplicity and to avoid the local
declaration and the method call, but i see the point in your advice.
I will debug the code with more detail.
Hans
On Fri, 07 May 2004 18:16:48
I think I know the answer to this, but I want to confirm it: if I
register a cleanup handler for a request, and the client is using
keep-alive or HTTP 1.1 persistent connections, will my handler run after
the current request finishes, or will it run after all requests made on
this connection
Perrin Harkins wrote:
I think I know the answer to this, but I want to confirm it: if I
register a cleanup handler for a request, and the client is using
keep-alive or HTTP 1.1 persistent connections, will my handler run after
the current request finishes, or will it run after all requests made
Stas Bekman wrote:
Perrin Harkins wrote:
I think I know the answer to this, but I want to confirm it: if I
register a cleanup handler for a request, and the client is using
keep-alive or HTTP 1.1 persistent connections, will my handler run after
the current request finishes
On Mon, 2004-05-10 at 14:48, Stas Bekman wrote:
It will run after each request regardless the connection type.
Thanks for the confirmation.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette:
I have a related question. I am using IPC::MM to pass shared information between
children in mod_perl, Apache 1.3, which is recommended by e.g. Perrin several times on
the list.
The memory can be cleaned up or re-use under a normal Perl program by mm_destroy($mm).
In mod_perl, is there a way
of the error_log. It doesn't look so bad... at first glance it looks like some
connections are being reused. And the message: Issuing rollback() for
database handle ... isn't generated in all the requests.
# 1: report about new connect
# 2: full debug output
$Apache::DBI::DEBUG = 2;
Begin of output
On Thu, 2004-05-06 at 12:42, Hans Poo R. wrote:
I removed the manual rollback and let the job to Apache::DBI, the problem is
that after the change, the message about the handle destroyed still appears in
the log. I activated the $Apache::DBI::DEBUG variable, but the message persist
(now with
Hi all
I'am using mod_perl-1.27, apache 1.3.28, Linux RedHat 9 and postgresql 7.4.2.
I want to know, if it's necessary to rollback database connections on each
request arrive with a PerlInitHandler, when using persistent database connections.
This is the way i'am doing now (rolling back
On Wed, 2004-05-05 at 13:01, Hans Poo R. wrote:
I want to know, if it's necessary to rollback database connections on each
request arrive with a PerlInitHandler, when using persistent database connections.
Apache::DBI already does that for you in a cleanup handler. You are
using Apache::DBI
. They each spend 3-6 hours a day
actually entering and changing data.
Currently most of the public side has been converted to Mod Perl. I'm
debating on weather converting the Admin side is going to be good or bad for
the server cause it means persistent 2 connections and I'm not sure how much
I'm a little confused - why would you use two apache processes for this?
It sounds like one would do just fine ...
-Original Message-
From: David Hofmann [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 2:54 PM
To: [EMAIL PROTECTED]
Subject: Connections
Currently I'm
On Thu, 2004-04-01 at 14:53, David Hofmann wrote:
Currently most of the public side has been converted to Mod Perl. I'm
debating on weather converting the Admin side is going to be good or bad for
the server cause it means persistent 2 connections and I'm not sure how much
load
Hi everyone, I'm fairly new to mod_perl but have been working with perl
for a few years now.
I have a site which connects to postgres, no idea whether it uses
persistent connections or not, as the custom modules built prior to me
looking at it goes pretty deep.
Connections to postgres are made
What you want to be using is Apache::DBI. Sounds like someone made a bad
attempt at making their own cached connections in the code you have.
Apache::DBI handles everything transparently for you. But you are going to
have to dig in and get rid of all the caching stuff that is currently in
your
70 matches
Mail list logo
