Mailing List Archive: Catalyst: Users

Re: Slow fastcgi: A debugging aid

Index | Next | Previous | View Threaded

ijw at cack

May 4, 2009, 7:15 AM

Post #1 of 9 (1295 views)
Permalink

Re: 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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

orasnita at gmail

May 4, 2009, 10:07 AM

Post #2 of 9 (1239 views)
Permalink

Re: Slow fastcgi: A debugging aid [In reply to]

From: "Ian Wells" <ijw [at] cack>
>> 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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

ijw at cack

May 4, 2009, 10:51 AM

Post #3 of 9 (1238 views)
Permalink

Re: Slow fastcgi: A debugging aid [In reply to]

> 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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

orasnita at gmail

May 4, 2009, 3:43 PM

Post #4 of 9 (1234 views)
Permalink

Re: Slow fastcgi: A debugging aid [In reply to]

From: "Ian Wells" <ijw [at] cack>
>> 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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

peter at peknet

May 4, 2009, 5:56 PM

Post #5 of 9 (1229 views)
Permalink

Re: Slow fastcgi: A debugging aid [In reply to]

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/ . peter [at] peknet

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

jon+catalyst at youramigo

May 4, 2009, 8:36 PM

Post #6 of 9 (1210 views)
Permalink

Re: Slow fastcgi: A debugging aid [In reply to]

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 Schutz My tech notes http://notes.jschutz.net
Chief Technology Officer http://www.youramigo.com
YourAmigo

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

bobtfish at bobtfish

May 5, 2009, 2:51 AM

Post #7 of 9 (1215 views)
Permalink

Re: Slow fastcgi: A debugging aid [In reply to]

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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

ash_cpan at firemirror

May 5, 2009, 3:32 AM

Post #8 of 9 (1207 views)
Permalink

Re: Slow fastcgi: A debugging aid [In reply to]

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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

dbix-class at trout

May 5, 2009, 3:56 AM

Post #9 of 9 (1205 views)
Permalink

Re: Slow fastcgi: A debugging aid [In reply to]

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.uk http://shadowcat.co.uk/blog/matt-s-trout/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads