On Fri, 10 Feb 2006 10:32:40 +, Paul Johnston wrote:
Hi Paul
> Any obvious optimisations for cgiapp? Any obvious places I should
> check?
Dan Horne and others have pointed you to the Cache::* module, which I too
recommend. But even then there are things to watch out for:
o By tracing throu
On Fri, 2006-02-10 at 20:18 +, Paul Johnston wrote:
> Regarding caching data - a file cache is almost never quicker than a DB
> based cache, *but* an in-memory cache available to all users is
> definitely quicker.
The two CPAN modules that consistently beat MySQL for speed are
Cache::FastMma
Paul Johnston wrote:
> Coming (back after 7 years) to perl from other languages there are
> certain things in other languages that you want to be available in
> perl. One of those things is from ColdFusion and is what I'm asking about.
welcome back
> In ColdFusion, you have "applications" and
Thanks for all your help regarding caching and queries and stuff.
I have experience of these kinds of things with many other languages,
just not really with perl, so you've given me a whole load of things to
look over and find out about.
Coming (back after 7 years) to perl from other language
On 2/10/06, Paul Johnston <[EMAIL PROTECTED]> wrote:
> >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 f
> From: Michael Peters [mailto:[EMAIL PROTECTED]
> Dan Horne wrote:
> >>The question stands though - is there a way to "cache" the query
> >>information for all users? Example: the app can be called from
> >>3 different domains, and using the domain information, load 3
> >>different sets of infor
Dan Horne wrote:
>>The question stands though - is there a way to "cache" the query
>>information for all users? Example: the app can be called from
>>3 different domains, and using the domain information, load 3
>>different sets of information and store them for every request
>>(changes eve
> The question stands though - is there a way to "cache" the query
> information for all users? Example: the app can be called from
> 3 different domains, and using the domain information, load 3
> different sets of information and store them for every request
> (changes every 15 minutes). D
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
Dan Horne wrote:
Optimising db connections: cutting down the number of DB connections per
request.
Paul, does your application need more than one connection per request? You
may be connecting to more than one database, schema or user, but if not,
then maybe you don't need so many connec
> Optimising db connections: cutting down the number of DB connections per
> request.
Paul, does your application need more than one connection per request? You
may be connecting to more than one database, schema or user, but if not,
then maybe you don't need so many connections. CGI::Applicatio
On Feb 10, 2006, at 11:50 AM, Paul Johnston wrote:
Is there a decent logging plugin for cgiapp? Would be REALLY
helpful to be able to just have a plugin for it.
CGI::Application::Plugin::LogDispatch. Check it out - it rocks!
Jason
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. Whe
Paul Johnston wrote:
> Just out of interest, is there anything specific (pitfalls, known
> issues) that I should be aware of when load testing applications built
> on cgiapp?
C::A is extremely lightweight (lighter than any other framework that I'm aware
of) so I doubt the problem is there. But,
14 matches
Mail list logo
