> 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,
[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
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 somet
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
On Thu, 30 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 lo
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 alr
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
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 te
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
do
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 "Apach
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 si
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 $u
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:
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
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 st
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 accidental
aching a prepared statement, 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 lookin
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
ebsite, I quickly saw
> a lot 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. Howeve
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 par
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
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
aching a prepared statement, 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 persistant connections ?
before looking into how dbd::pg is internally handling the prepared
stateme
.html
Any suggestions? I 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=msg&th=4598&start=0&;
There the fix involved putting using DEALLOCATE whe
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?
T
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 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 ye
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 Python
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 authenticatio
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 ev
t 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
I fwd'd this to a friend with commit access to twisted. hopefully
i'll get a response on clarification.
But from what I understand, the Twisted networking framework works
like this:
The twisted 'reactor' is single threaded. It uses select by
default, you can use poll. The docs suggest
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 Pytho
mption.
Our email connection management software starts 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
hat dissimilar to yours- I was tempted to go with a scheme solution
based on continuations, 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 co
> 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 m
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 s
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
se server has a maximum of 400
> connections, so it makes sense that our total count of Apache processes
> should be less than that.
You should also check to make sure that you are really opening only one
connection per process. You can use the Apache::DBI debugging to check
that on your dev ser
t; 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
>
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.
T
L 7.4 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,
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.
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 PerlInitHandl
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 H
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.
Sounds like you want to disable HTTP Pipelining, am I mistaken? If not,
Apache already has a mechanism for this, look in the default
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 do
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 ch
[ 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 valu
andal 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
Hi Everyone !
Currently, I am implementing a mechanism to restrict the number of
parallel connections to the server from a single client/user.
The mechanis is something like :
- Use Cache::FastMmap to share the data between multiple processes.
- PerlAccessHandler will get the key for cache to
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
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
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
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
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 yo
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 (f
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), this is
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 to
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: http://perl.apach
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
>> th
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 on
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
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 -0
On Fri, 2004-05-07 at 17:03, Hans Poo R. wrote:
> Fosis::handler is the main Dispatcher of the dynamic content. It can use the
> database handler via a Global variable $dbh
It's not a good practice to put a database handle in a global.
Apache::DBI does it, but it also pings the handle before usin
tput
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
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 wit
2004 14:03:02 -0400, Perrin Harkins wrote
> 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
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
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 no
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 ho
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
ted 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 that will put on the server since the majority of
> the time the server not using
more. 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 no
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
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
76 matches
Mail list logo