(Hopefully I'm not out of my depth here) I feel your pain WRT Oracle connections as we've had similar complaints from our DBA overlords about the number of connections our app was making here at $work. Do you have your mod_perl processes behind some sort of proxy? If you run your mod_perl application in the same apache instance that serves static content any child that is spawned, even if it's just for serving HTML or an image file, will be fully functional (including having a database connection for each catalyst app that is hosted on that server). You might consider changing how your application is deployed and use FastCGI (or mod_perl behind a proxy) so that it's easier to control the number of processes (and therefore database connections) you spin up.
On Wed, Sep 8, 2010 at 10:46 AM, Stuart Watt <sw...@infobal.com> wrote: > Sounds like a job for DBD::Proxy or DBD::Gofer, not that I've ever used > them, and I have no idea whether they would play nice with DBIC -- the DBIC > folks would have a better grasp on that question. That would leave the > Catalyst parts unchanged apart from configuration, which would be a good > thing architecturally. > > --S > > Stuart Watt > ARM Product Developer > Information Balance > > On 9/8/2010 10:54 AM, Simon Miner wrote: > > Thanks for the responses, > > Jason, I don't think reducing the number of database connections will hurt > responsiveness. Even though there are 3 separate Catalyst apps, each HTTP > request will only involve one of them (since they all run out of the same > web server), so there should never be contention between the apps for the > shared database connection. Does this make sense? > > Tom and Nicholas, I wish this was premature optimization, but my > organization has experienced serious performance issues in the past related > to multiple (Oracle) database connections per HTTP server process. Extra > Oracle connections are expensive to maintain, particularly on the database > server, and so we've tried to ensure that a single server process only has a > single connection to a given database (since that's all it should need at > any given time). > > I've attached a Devel::NYTProf screenshot for one of the server processes I > profiled this morning. Looks like it confirms the multiple database > connections. > > So back to initial question -- How do I update the models of my three > Catalyst apps to share a single Oracle database connection? > > Thanks again. I really appreciate your feedback. > > Simon > > On Tue, Sep 7, 2010 at 11:40 PM, Nicholas Wehr < > catal...@bionikchickens.com> wrote: > >> I'm with Tom on this one. Unless you've narrowed all optimization efforts >> and this is all you have left - it could be worth a try.. but as Jason >> points out, you may not gain a thing. I'd recommend profiling your code and >> tracking down performance issues from that base level. Please post your >> results - I've very curious! >> >> -nw >> >> >> On Tue, Sep 7, 2010 at 7:21 PM, Tomas Doran <bobtf...@bobtfish.net>wrote: >> >>> >>> On 7 Sep 2010, at 18:59, Simon Miner wrote: >>> >>>> All three of these apps run under a single Apache 1.3.42/mod_perl 1.31 >>>> server. >>>> >>> >>> Wow, mod_perl 1.... Ok then :) >>> >>> >>> It appears that each server process creates a unique database >>>> connection variable for each of these apps. Although these database >>>> connections get reused from request to request, I would like to make things >>>> even more efficient by having a single database connection variable per >>>> server process which gets shared across all 3 Catalyst apps. >>>> >>> >>> Why do you think that this will help or affect anything? >>> >>> I.e. is this not premature optimisation? >>> >>> Cheers >>> t0m >>> >>> >>> >>> _______________________________________________ >>> List: Catalyst@lists.scsys.co.uk >>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >>> Searchable archive: >>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ >>> Dev site: http://dev.catalyst.perl.org/ >>> >> >> >> _______________________________________________ >> List: Catalyst@lists.scsys.co.uk >> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >> Searchable archive: >> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ >> Dev site: http://dev.catalyst.perl.org/ >> >> > > > -- > -- Simon > > -- > This message was scanned by ESVA and is believed to be clean. > Click here to report this message as > spam.<http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=7897728072.B3B1D> > > > _______________________________________________ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > > > _______________________________________________ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > >
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
