Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-12 Thread Chris
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 database server > > > > – or not bei

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-12 Thread tomcat/perl
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 in scenarios most developers can

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-11 Thread Chris
gt; > without the risks > > involved [other than the “lock table” issue]. > > > > __ __ > > > > __ __ > > > > *From:*Mithun Bhattacharya mailto:mit...@gmail.com>> > > *Sent:* 09 February 2021 18:34 > > *To:* m

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-11 Thread tomcat/perl
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 - performance and

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-09 Thread Dave Morgan
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

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-09 Thread Mithun Bhattacharya
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 ExecCG

RE: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-09 Thread James Smith
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 - performance and

RE: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-09 Thread James Smith
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

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-09 Thread Clive Eisen
> 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

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-09 Thread Rafael Caceres
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

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-09 Thread Clive Eisen
> 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

RE: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-09 Thread James Smith
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 all. > Never had

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-09 Thread Mithun Bhattacharya
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

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-09 Thread Vincent Veyron
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

RE: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-08 Thread James Smith
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? Thanks. On Mon

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-07 Thread Wesley Peng
ely 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.apache.org >

RE: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-07 Thread James Smith
; 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 2:23 PM James Smith

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-07 Thread Mithun Bhattacharya
dperl@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'll end > > up needing a bit

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-07 Thread John Dunlap
y 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.apache.org >

RE: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-07 Thread James Smith
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'll end > up need

Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-07 Thread Vincent Veyron
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

RE: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-07 Thread Steven Haigh
l step to cd to the script directory – which might be your issue…. *From:*Steven Haigh *Sent:* 07 February 2021 01:00 *To:* modperl@perl.apache.org *Subject:* Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT] Hi all, So for many years I've been slack and writin

RE: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-07 Thread Steven Haigh
perl.apache.org *Subject:* Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT] Hi all, So for many years I've been slack and writing perl scripts to do various things - but never needed more than the normal apache +ExecCGI and Template Toolkit. One of my sites has become a

RE: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]

2021-02-07 Thread James Smith
n from using them} It suggests you use ModPerl/PerlRunPrefork – as this does an additional step to cd to the script directory – which might be your issue…. From: Steven Haigh Sent: 07 February 2021 01:00 To: modperl@perl.apache.org Subject: Moving ExecCGI to mod_perl - performance and custom 'modules