these up}
> > > >
> > > > If you are working with e.g. with MySQL the overhead of the
> > > > (socket) connection is
> > > > very small, but having more connections open to cope with
> > > > persistent connections
> > > > {memory wise} often needs specifying a much large
;>
*Sent:* 09 February 2021 18:34
*To:* mod_perl list mailto:modperl@perl.apache.org>>
*Subject:* Re: Moving ExecCGI to mod_perl - performance and custom
'modules' [EXT]
__ __
Connection caching does work for most use cases - we have to accept James
works i
the benefits of caching
> > without the risks
> > involved [other than the “lock table” issue].
> >
> > __ __
> >
> > __ __
> >
> > *From:*Mithun Bhattacharya mailto:mit...@gmail.com>>
> > *Sent:* 09 February 20
other than the “lock table” issue].
__ __
__ __
*From:*Mithun Bhattacharya mailto:mit...@gmail.com>>
*Sent:* 09 February 2021 18:34
*To:* mod_perl list mailto:modperl@perl.apache.org>>
*Subject:* Re: Moving ExecCGI to mod_perl - perfor
As a long time Oracle DBA and perl mangler I have refrained from joining
this conversation until now.
Connection caching is a configuration option in DBI, not a coding
requirement. For web servers it is a single line edit in startup.pl
import DBICache versus import DBI if I recall incorrectly.
hich you open/close on a per request
> basis gives you the benefits of caching without the risks involved [other
> than the “lock table” issue].
>
>
>
>
>
> *From:* Mithun Bhattacharya
> *Sent:* 09 February 2021 18:34
> *To:* mod_perl list
> *Subject:* Re: Moving E
t access to the other machines - taking servers + desktop machines -
something like 30-50K cores.
-Original Message-
From: Clive Eisen
Sent: 09 February 2021 19:23
To: Rafael Caceres
Cc: James Smith ; Vincent Veyron ;
modperl@perl.apache.org
Subject: Re: Moving ExecCGI to mod_perl - p
keep
open and which you open/close on a per request basis gives you the benefits of
caching without the risks involved [other than the “lock table” issue].
From: Mithun Bhattacharya
Sent: 09 February 2021 18:34
To: mod_perl list
Subject: Re: Moving ExecCGI to mod_perl - performance and cu
> On 9 Feb 2021, at 19:16, Rafael Caceres wrote:
>
> Another thing that can be done is keep the app server + DB inside your LAN
> and place a reverse proxy on your DMZ, that adds some level of protection.
Not really - the only protection is if all your apis or web pages are secure -
the reve
Another thing that can be done is keep the app server + DB inside your LAN and
place a reverse proxy on your DMZ, that adds some level of protection.
Rafael
On Feb 9, 2021, 2:08 PM -0500, Clive Eisen , wrote:
On 9 Feb 2021, at 18:45, James Smith wrote:
It doesn't matter what db - and whether
> On 9 Feb 2021, at 18:45, James Smith wrote:
>
> It doesn't matter what db - and whether you wrap it in eval it is a problem
> (postgres has a similar problem - the one with least problems is MySQL) - if
> you have a secure environment where your databases are in a firewalled zone
> it will
ExecCGI to mod_perl - performance and custom 'modules' [EXT]
On Sun, 7 Feb 2021 20:21:34 +
James Smith wrote:
Hi James,
> DBI sharing doesn't really gain you much - and can actually lead you into a
> whole world of pain. It isn't actually worth turning it on at
Connection caching does work for most use cases - we have to accept James
works in scenarios most developers can't fathom :)
If you are just firing off simple SQL's without any triggers or named
temporary tables involved you should be good. The only times we recall
tripping on cached connection is
On Sun, 7 Feb 2021 20:21:34 +
James Smith wrote:
Hi James,
> DBI sharing doesn't really gain you much - and can actually lead you into a
> whole world of pain. It isn't actually worth turning it on at all.
>
Never had a problem with it myself in years of using it, but I wrap my queries
i
web and servers for
instance}
From: Wesley Peng
Sent: 08 February 2021 00:29
To: modperl@perl.apache.org
Subject: Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]
what's DBI sharing? do you mean Apache::DBI?
Does perl has Java similar DB connection pool?
r of approximately 50-100 child apaches,
> meant we ended up blowing up the connections to the database server really
> quickly...
>
>
> -Original Message-
> From: Vincent Veyron
> Sent: 07 February 2021 19:06
> To: Steven Haigh
> Cc: James Smith ; modperl@perl.
; Steven Haigh ;
modperl@perl.apache.org
Subject: Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]
DBI sharing has it's own issues but in most use cases it does a pretty good job
and keeps the DBA's happy - that is very important ;)
On Sun, Feb 7, 2021 at
James Smith ; modperl@perl.apache.org
> Subject: Re: Moving ExecCGI to mod_perl - performance and custom 'modules'
> [EXT]
>
> On Sun, 07 Feb 2021 23:58:17 +1100
> Steven Haigh wrote:
> >
> > I haven't gotten into the preload or DBI sharing yet - as tha
of approximately 50-100
> child apaches, meant we ended up blowing up the connections to the database
> server really quickly...
>
>
> -Original Message-
> From: Vincent Veyron
> Sent: 07 February 2021 19:06
> To: Steven Haigh
> Cc: James Smith ; modperl@perl.apac
1 19:06
To: Steven Haigh
Cc: James Smith ; modperl@perl.apache.org
Subject: Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]
On Sun, 07 Feb 2021 23:58:17 +1100
Steven Haigh wrote:
>
> I haven't gotten into the preload or DBI sharing yet - as that&
On Sun, 07 Feb 2021 23:58:17 +1100
Steven Haigh wrote:
>
> I haven't gotten into the preload or DBI sharing yet - as that'll end
> up needing a bit of a rewrite of code to take advantage of. I'd be open
> to suggestions here from those who have done it in the past to save me
> going down some
In fact, I just realised that 'ab' test is rather restrictive So
here's a bit more of an extended test:
# ab -k -n 1000 -c 32
Apache + ExecCGI:
Requests per second:14.26 [#/sec] (mean)
Time per request: 2244.181 [ms] (mean)
Time per request: 70.131 [ms] (mea
Interestingly, I did get things working with ModPerl::PerlRegistry.
What I couldn't find *anywhere* is that the data I was loading in
Template Toolkit was included in the file in the __DATA__ area - which
causes mod_perl to fall over!
The only way I managed to find this was the following erro
As welsey said – try Registry, that was the standard way of using mod_perl to
cache perl in the server – but your problem might be due to the note in
PerlRun…
https://perl.apache.org/docs/2.0/api/ModPerl/PerlRun.html#Description
META: document that for now we don't chdir() into the script's dir
24 matches
Mail list logo
