Paul Johnston wrote:
> Michael et al,
>
> Thanks for all the suggestions. The dbprof one is very useful, and
> actually I've figured that the problem is 95% to do with the logging
> I've setup in the system.
>
> The bottleneck was in the fact I set up logging to debug the
> applications easily, and it's writing to a file. When load testing,
> it's doing lots of writes per connection, and I reckon that's where the
> bottleneck is. Turning it off didn't make that much difference, but it
> did make enough. Still think that it could be my apache setup though.
>
> Is there a decent logging plugin for cgiapp? Would be REALLY helpful to
> be able to just have a plugin for it.
Log::Dispatch should work well for you. One thing to remember about logging in
general is to check for the correct log level before generating complex logging
statements. For instance (using CAP::LogDispatch as an example)
use Data::Dumper;
...
$self->log->debug("Some struct: " . Dumper($some_struct);
That's bad. It should be something like
if( $self->log->would_log('debug') ) {
required Data::Dumper;
$self->log->debug("Some struct: " . Data::Dumper::Dumper($some_struct));
}
Not only does it delay the loading of Data::Dumper until it's needed, but it
saves the time to actually generate the dumped structure which will only be used
if the level is turned to 'debug'.
> I picked cgiapp because it is lightweight. I haven't got access to put
> mod_perl on the server, so I'm having to go straight cgi, but as soon as
> the site goes to it's own server, mod_perl is going straight on!
>
>> How did you optimize your db connections?
>>
>>
>
> Optimising db connections: cutting down the number of DB connections per
> request. I remember load testing and doing quality assurance on a UK
> government website (to remain nameless), and the front page (and pretty
> much every subsequent page) was making 50+ database calls per request.
> They were wondering why it was going slow. So optimising the database
> connections is about figuring out how to get the Database to do the work
> it should be doing, and doing as few calls as possible within each request.
I was asking to see if you were perhaps using Apache::DBI to cut down on
connection overhead, but since it's not under mod_perl then that's a no go.
> Would be helpful if there was a way of caching the contents of a query
> within an application though. So that 1 database result set is stored
> for every user for a set period of time. Anyone?
Caching at the application level is harder than it appears in most cases,
especially when you're not using a persistant environment (like mod_perl). I
would look at turning on caching at the DB level though if you can.
--
Michael Peters
Developer
Plus Three, LP
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
