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
I would consider mine a small setup on an internal network and I have used both Sybase and SQL Server. In our case the DBA's preferred us to remain connected rather than make too many connections - we need DB access in bursts - it could be quiet for more than an hour and then suddenly we might

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

2021-02-09 Thread James Smith
The advantage of the web proxy is not from securing your app - although there are things you can do on the reverse proxy to secure less secure apps It's main advantage is that it doesn't run a large software stack - and so it makes it harder for people to compromise your front end and then

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

2021-02-09 Thread James Smith
Mithun, Iā€™m not sure on what scale you work ā€“ but these are from experience in sites with small to medium load ā€“ and we rarely see an appreciable gain in using cached or pooled connections, just the occasional heartache they cause. If you are working on small applications with a minimal number

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
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 happen to all of them... It's a nasty bit of networking -

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