Re: [Catalyst] Slow fastcgi: A debugging aid
> On 4 May 2009, at 09:19, Octavian Rasnita wrote: >> >> I have started using fastcgi with a Catalyst app, using it as an external >> server, but I've seen that it works very slow and many requests give a >> timeout error and display a 500 error because of this. This is a fairly standard sort of problem, so have a debugging aid: http://dev.catalystframework.org/wiki/gettingstarted/howtos/quick_and_dirty_FastCGI The idea here is that this produces a 'known good' minimal FastCGI implementation. Unfortunately, I can't test this properly at the moment due to issues with my development server, but please: - try it - ask me if you have problems, but if you have fixes, change the page! - simplify the page and script if at all possible. *Don't* make it more like a production environment - it's not supposed to be a production environment. *Do* remove any possible complexity (I would prefer a config file to a perl script if at all possible, but lighttpd seems to want absolute paths.) The idea is to remove one variable from an otherwise difficult question. 'My FastCGI setup with server a, configuration b and my custom application' becomes 'my custom application, running in this standard fastcgi configuration'... Cheers, -- Ian. ___ 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/
Re: [Catalyst] Slow fastcgi: A debugging aid
From: "Ian Wells" On 4 May 2009, at 09:19, Octavian Rasnita wrote: I have started using fastcgi with a Catalyst app, using it as an external server, but I've seen that it works very slow and many requests give a timeout error and display a 500 error because of this. This is a fairly standard sort of problem, so have a debugging aid: http://dev.catalystframework.org/wiki/gettingstarted/howtos/quick_and_dirty_FastCGI The idea here is that this produces a 'known good' minimal FastCGI implementation. Unfortunately, I can't test this properly at the moment due to issues with my development server, but please: - try it - ask me if you have problems, but if you have fixes, change the page! Hi, I tried it, but it gave the following error which I don't understand: 2009-05-04 20:04:04: (plugin.c.165) dlopen() failed for: /usr/lib64/lighttpd/mod_fastcgi.so /usr/lib64/lighttpd/mod_fastcgi.so: cannot open shared object file: No such file or directory 2009-05-04 20:04:04: (server.c.621) loading plugins finally failed Thanks. Octavian ___ 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/
Re: [Catalyst] Slow fastcgi: A debugging aid
> I tried it, but it gave the following error which I don't understand: > > 2009-05-04 20:04:04: (plugin.c.165) dlopen() failed for: > /usr/lib64/lighttpd/mod_fastcgi.so /usr/lib64/lighttpd/mod_fastcgi.so: > cannot open shared object file: No such file or directory > 2009-05-04 20:04:04: (server.c.621) loading plugins finally failed You're missing the fastcgi plugin for lighttpd. How did you install lighttpd and what OS are you using? (Off-list, if I can fix the problem for you I'll summarise it.) -- Ian. ___ 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/
Re: [Catalyst] Slow fastcgi: A debugging aid
From: "Ian Wells" I tried it, but it gave the following error which I don't understand: 2009-05-04 20:04:04: (plugin.c.165) dlopen() failed for: /usr/lib64/lighttpd/mod_fastcgi.so /usr/lib64/lighttpd/mod_fastcgi.so: cannot open shared object file: No such file or directory 2009-05-04 20:04:04: (server.c.621) loading plugins finally failed You're missing the fastcgi plugin for lighttpd. How did you install lighttpd and what OS are you using? I use Fedora and I installed lighttpd with yum install ... Anyway, there are many things to say, but the result is that I went back to perl 5.8.8 and mod_perl. My development and test server is under Windows and the production server under Linux, so because perl is not a really fully portable language, I also need to do tests under the production server, which is not very nice. So going back to mod_perl was the easiest solution. When I used fastcgi, I've seen that the system started to swap, to fill almost the entire swap, and this is a sign that it might have big memory leaks. This is not a big issue with mod_perl but it is with fastcgi, and using other servers don't help very much. It would be nice to be able to limit the number of requests per fastcgi child process... Octavian ___ 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/
Re: [Catalyst] Slow fastcgi: A debugging aid
Octavian Râsnita wrote on 5/4/09 5:43 PM: > It would be nice to be able to limit the number of requests per fastcgi > child process... Catalyst::Plugin::AutoRestart -- Peter Karman . http://peknet.com/ . pe...@peknet.com ___ 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/
Re: [Catalyst] Slow fastcgi: A debugging aid
Octavian Râsnita wrote on 5/4/09 5:43 PM: > It would be nice to be able to limit the number of requests per fastcgi > child process... On Mon, 2009-05-04 at 19:56 -0500, Peter Karman wrote: > Catalyst::Plugin::AutoRestart > Would I be correct in my reading of the code, that since the exit() happens in handle_request, the request that triggers the restart does not get served? I did a similar thing by subclassing FCGI::ProcManager and adding the restart logic into pm_post_dispatch so the restart does not interfere with any current requests. The subclass name is passed to the start-up script with the -M option. Would be nicer to be able to do this in a plugin, of course, but I couldn't at the time see any post-request hooks in Catalyst itself that could be used to ensure that the full request cycle completes before the server restarts. -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ 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/
Re: [Catalyst] Slow fastcgi: A debugging aid
Octavian Râsnita wrote: My development and test server is under Windows and the production server under Linux, so because perl is not a really fully portable language, I also need to do tests under the production server, which is not very nice. If your development environment doesn't look as close to production as possible, then you're going to want/need to do tests on something which *does* look like your production environment. This isn't a perl specific thing _in any way_, you'll find inter-platform differences no matter what language and runtime stack you use. 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/
Re: [Catalyst] Slow fastcgi: A debugging aid
On 5 May 2009, at 04:36, Jon Schutz wrote: Octavian Râsnita wrote on 5/4/09 5:43 PM: It would be nice to be able to limit the number of requests per fastcgi child process... On Mon, 2009-05-04 at 19:56 -0500, Peter Karman wrote: Catalyst::Plugin::AutoRestart Would I be correct in my reading of the code, that since the exit() happens in handle_request, the request that triggers the restart does not get served? No, Since the second line is my $ret = $c->next::method(@args); This does the normal request handling first (including writing any data) then it checks the process. -ash ___ 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/
Re: [Catalyst] Slow fastcgi: A debugging aid
On Tue, May 05, 2009 at 01:06:52PM +0930, Jon Schutz wrote: > On Mon, 2009-05-04 at 19:56 -0500, Peter Karman wrote: > > > Catalyst::Plugin::AutoRestart > > > > Would I be correct in my reading of the code, that since the exit() > happens in handle_request, the request that triggers the restart does > not get served? No. The first thing this code does is call next::method to do the full normal handle_request processing. I worked with John and John on this plugin; it's rock solid and Shadowcat have used it for almost every client since. -- Matt S Trout Catalyst and DBIx::Class consultancy with a clue Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/ Shadowcat Systems Limited mst (@) shadowcat.co.ukhttp://shadowcat.co.uk/blog/matt-s-trout/ ___ 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/
