Mailing List Archive: Cherokee: users

504 Gateway timeouts under minimal load

Index | Next | Previous | View Threaded

thebigslide at gmail

Feb 3, 2010, 10:04 AM

Post #1 of 17 (1211 views)
Permalink

504 Gateway timeouts under minimal load

Hi,

I'm using Cherokee in production for the second time - as a front end to a
mid-volume web application.

The front end server sees about 40-50 TCP connections/s at most with 100-120
HTTP connections/s
I'm noticing occasional 504 Gateway timeout errors (mostly reported by
customers during periods of high usage)

The server is a quad core 3.2GHz 32-bit x86 machine with 3GB of RAM.
Load average during high usage is around 0.4
ulimit -n is set to 1024
lsof -n | grep cherokee | wc -l reports 750ish during high usage.
Throughput is about 2mbyte/s
Cherokee is barely touching the CPU (20% tops) and disk i/o wait is hovering
around 4% on a fast SCSI RAID array.
I'm running v0.99.42 compiled under debian lenny with default options.

The website serves images, css and js directly and reverse proxy's php
requests to 2 round-robin app servers on a local 100mbit network. It's the
reverse proxy requests that are producing the 504 timeout errors. The app
servers are reporting no errors and have timeouts configured 5s lower than
the reverse proxy (which is set to 60 seconds).
Reuse connections is set to 48.
Compression is disabled for the reverse proxies.

Please help me figure out what these timeouts are occuring. I'm willing and
able to do whatever debugging is necessary to figure this out, but I'm at
the limits of my own know-how.

Some further debugging steps would be really helpful.

alvaro at octality

Feb 7, 2010, 1:49 PM

Post #2 of 17 (1185 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

On 03/02/2010, at 19:04, Ryan McIntosh wrote:

> The server is a quad core 3.2GHz 32-bit x86 machine with 3GB of RAM.
> Load average during high usage is around 0.4
> ulimit -n is set to 1024
> lsof -n | grep cherokee | wc -l reports 750ish during high usage.
> Throughput is about 2mbyte/s
> Cherokee is barely touching the CPU (20% tops) and disk i/o wait is hovering around 4% on a fast SCSI RAID array.
> I'm running v0.99.42 compiled under debian lenny with default options.
>
> The website serves images, css and js directly and reverse proxy's php requests to 2 round-robin app servers on a local 100mbit network. It's the reverse proxy requests that are producing the 504 timeout errors. The app servers are reporting no errors and have timeouts configured 5s lower than the reverse proxy (which is set to 60 seconds).
> Reuse connections is set to 48.
> Compression is disabled for the reverse proxies.
>
> Please help me figure out what these timeouts are occuring. I'm willing and able to do whatever debugging is necessary to figure this out, but I'm at the limits of my own know-how.
>
> Some further debugging steps would be really helpful.

Have you tried to raise the file descriptor limit? In cherokee-admin, go to Advanced ➠ Resources ➠ File Descriptors. I'd try raising it to at least 8k.

--
Octality
http://www.octality.com/

_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

paul.m.bailey at gmail

Feb 8, 2010, 4:08 PM

Post #3 of 17 (1176 views)
Permalink

504 Gateway timeouts under minimal load [In reply to]

Seeing the same 504 issue with moderate loads. Tried to change descriptor
to 4096 but still no dice. I'm using a uWsgi setup.

Just recently switched to Cherokee because it is fast and awesome to use.
Performance wise with uWsgi it blows everything out of the water but going
to have to go back to Apache if I can't find a work around soon to keep it
stable.

paul.m.bailey at gmail

Feb 8, 2010, 6:48 PM

Post #4 of 17 (1178 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

I can recreate the problem by just hitting a page with about 90 requests in
5 seconds. So I guess about 20 requests per second.

It looks like it is only happening with uWsgi requests. Static pages seem
to work great.

My current command line options for uWsgi are:
/usr/bin/uwsgi -s 127.0.0.1:45516 -t 60 -M -p 10 -C -x /......../uwsgi.xml

I've tried playing with -t and -p but doesn't seem to change the outcome. I
guess I'll check over at uWsgi for more trouble shooting.

roberto at unbit

Feb 8, 2010, 11:34 PM

Post #5 of 17 (1177 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

> I can recreate the problem by just hitting a page with about 90 requests
> in
> 5 seconds. So I guess about 20 requests per second.
>
> It looks like it is only happening with uWsgi requests. Static pages seem
> to work great.
>
> My current command line options for uWsgi are:
> /usr/bin/uwsgi -s 127.0.0.1:45516 -t 60 -M -p 10 -C -x
> /......../uwsgi.xml
>
> I've tried playing with -t and -p but doesn't seem to change the outcome.
> I
> guess I'll check over at uWsgi for more trouble shooting.

I Paul, you have to check the uWSGI server log. If it is a configuration
problem it will log it.

Remember that uWSGI is very conservative by default. It will not spawn
other workers if the load increment but the hardware resources are not
enough so if your 10 processes is not enough you have to increase them.

- But increasing processes rarely is a solution -

I bet that your problem is on the socket-side. Look at the -z (internal
timeout) and -l (socket backlog) options. Put them at large value like
-z 30 -l 128 and the cherokee timeout should go away. They are value that
are "application" dependent so do not try to find a "work-for-all" value.

--
Roberto De Ioris
http://unbit.it
--

_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

paul.m.bailey at gmail

Feb 11, 2010, 9:53 AM

Post #6 of 17 (1178 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

Ok I think the options you gave helped but it seemed like Cherokee was
timing out prematurely still.

So I changed�"Connections timeout" under my uWsgi handler and it seems
to wait longer now before giving a 504 which is want I wanted. I also
added some more uWsgi processes to load balance on.

Thanks for the help!

On Tue, Feb 9, 2010 at 1:34 AM, Roberto De Ioris <roberto [at] unbit> wrote:
>
> > I can recreate the problem by just hitting a page with about 90 requests
> > in
> > 5 seconds. �So I guess about 20 requests per second.
> >
> > It looks like it is only happening with uWsgi requests. �Static pages seem
> > to work great.
> >
> > My current command line options for uWsgi are:
> > /usr/bin/uwsgi -s 127.0.0.1:45516 -t 60 -M -p 10 -C �-x
> > /......../uwsgi.xml
> >
> > I've tried playing with -t and -p but doesn't seem to change the outcome.
> > I
> > guess I'll check over at uWsgi for more trouble shooting.
>
>
> I Paul, you have to check the uWSGI server log. If it is a configuration
> problem it will log it.
>
> Remember that uWSGI is very conservative by default. It will not spawn
> other workers if the load increment but the hardware resources are not
> enough so if your 10 processes is not enough you have to increase them.
>
> �- But increasing processes rarely is a solution -
>
> I bet that your problem is on the socket-side. Look at the -z (internal
> timeout) and -l (socket backlog) options. Put them at large value like
> -z 30 -l 128 and the cherokee timeout should go away. They are value that
> are "application" dependent so do not try to find a "work-for-all" value.
>
>
> --
> Roberto De Ioris
> http://unbit.it
> --
>
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

guitarift at gmail

Feb 11, 2010, 5:41 PM

Post #7 of 17 (1160 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

I was experiencing the same issue. I tried changing my uwsgi command options
(l and z) but it didn't help.
I decided to try out Alvaro's suggestion and it worked!

File descriptor is automatically set to: ulimit -n. My ulimit -n was 1024.
Changed File descriptor to 10000 and it resolved the issue.
I'm not sure why this is required but thanks for the help Alvaro.

> > The server is a quad core 3.2GHz 32-bit x86 machine with 3GB of RAM.
> > Load average during high usage is around 0.4
> > ulimit -n is set to 1024
> > lsof -n | grep cherokee | wc -l reports 750ish during high usage.
> > Throughput is about 2mbyte/s
> > Cherokee is barely touching the CPU (20% tops) and disk i/o wait is
> hovering around 4% on a fast SCSI RAID array.
> > I'm running v0.99.42 compiled under debian lenny with default options.
> >
> > The website serves images, css and js directly and reverse proxy's php
> requests to 2 round-robin app servers on a local 100mbit network. It's the
> reverse proxy requests that are producing the 504 timeout errors. The app
> servers are reporting no errors and have timeouts configured 5s lower than
> the reverse proxy (which is set to 60 seconds).
> > Reuse connections is set to 48.
> > Compression is disabled for the reverse proxies.
> >
> > Please help me figure out what these timeouts are occuring. I'm willing
> and able to do whatever debugging is necessary to figure this out, but I'm
> at the limits of my own know-how.
> >
> > Some further debugging steps would be really helpful.
>
> Have you tried to raise the file descriptor limit? In cherokee-admin, go to
> Advanced ➠ Resources ➠ File Descriptors. I'd try raising it to at least 8k.
>
> --
> Octality
> http://www.octality.com/
>
> _______________________________________________
> Cherokee mailing list
> Cherokee [at] lists
> http://lists.octality.com/listinfo/cherokee
>

boteeka at yahoo

Feb 16, 2010, 3:47 AM

Post #8 of 17 (1154 views)
Permalink

504 Gateway timeouts under minimal load [In reply to]

Hi,

Probably my problem is something else as I don't use uWsgi at all, but you'll decide.

My virtualhost setup has a php fcgi handler, which I suspect to be the cause of the problems. Whenever a Gatewat Timeout occurs it doesn't stop giving me timeouts until I manually kill the php-cgi process. No amount of Cherokee restarting helps (either from the webadmin interface or by using standard Ubuntu commands like: sudo service cherokee {stop|start}). The only solution is to kill the php-cgi process, but sadly it doesn't last more than a couple of requests, then all starts over again.

I have a suspicion that the timeouts happen most often with AJAX requests, than normal requests, and after an AJAX request produces the timeout neither types of requests work anymore.
I am doing AJAX request with jQuery's (v. 1.4.1) $.get and $.getJSON methods and with the jQuery AjaxForm plugin.

I use the Symfony php framework (v. 1.2.10), compression is off (both in symfony and in cherokee), I/O cache is off.

This all started around the release of cherokee 0.99.3x.
My machine(s) all run Ubuntu 9.10 64bit.

As for the minimal load, this is happening on my dev machine where only I am using the webserver at a rate of about max. 10 request per minute.

Ideas? Suggestions?

Regards,

Botond Szasz

_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

reidrac at usebox

Feb 18, 2010, 2:22 AM

Post #9 of 17 (1140 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

El mar, 16-02-2010 a las 03:47 -0800, Szász Botond escribió:
> [...]
> As for the minimal load, this is happening on my dev machine where only I am using the webserver at a rate of about max. 10 request per minute.
>
> Ideas? Suggestions?

Hi,

How many PHP processes hare you spawning? If you have only one process
for PHP (with children serving stuff), when the only one PHP process is
busy you will get that error (if I recall correctly, I have the same
problem at first).

Check this:

http://www.fastcgi.com/archives/fastcgi-developers/2009-April/000230.html

Juanjo

--
jjm's home: http://www.usebox.net/jjm/
blackshell: http://blackshell.usebox.net/
ramble on: http://rambleon.usebox.net/

_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

abarrera at neurosecurity

Feb 18, 2010, 2:28 AM

Post #10 of 17 (1140 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

On Thursday 18 February 2010 11:22:27 Juan J." Martínez wrote:
> El mar, 16-02-2010 a las 03:47 -0800, Szász Botond escribió:
> > [...]
> > As for the minimal load, this is happening on my dev machine where only I
> > am using the webserver at a rate of about max. 10 request per minute.
> >
> > Ideas? Suggestions?
>
> Hi,
>
> How many PHP processes hare you spawning? If you have only one process
> for PHP (with children serving stuff), when the only one PHP process is
> busy you will get that error (if I recall correctly, I have the same
> problem at first).
>
> Check this:
>
> http://www.fastcgi.com/archives/fastcgi-developers/2009-April/000230.html
>

Because this is happening a lot, maybe having an autospawn option might be a good idea ;) What do you
think about it?

> Juanjo
>

--
http://www.neurosecurity.com

"We must be the change we wish to see in the world"
Mahatma Gandhi
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

alvaro at octality

Feb 18, 2010, 2:48 AM

Post #11 of 17 (1150 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

On 18/02/2010, at 11:28, Alejandro Barrera wrote:
> On Thursday 18 February 2010 11:22:27 Juan J." Mart�nez wrote:
>> El mar, 16-02-2010 a las 03:47 -0800, Sz�sz Botond escribi�:
>>> [...]
>>> As for the minimal load, this is happening on my dev machine where only I
>>> am using the webserver at a rate of about max. 10 request per minute.
>>>
>>> Ideas? Suggestions?
>>
>> Hi,
>>
>> How many PHP processes hare you spawning? If you have only one process
>> for PHP (with children serving stuff), when the only one PHP process is
>> busy you will get that error (if I recall correctly, I have the same
>> problem at first).
>>
>> Check this:
>>
>> http://www.fastcgi.com/archives/fastcgi-developers/2009-April/000230.html
>
> Because this is happening a lot, maybe having an autospawn option might be a good idea ;) What do you think about it?

Cherokee does, in fact, spawn processes if needed. Basically, it launches a new process whenever it cannot contact the PHP interpreter (the connection is refused), that's a piece of cake. However, the tough scenario here is when the connection is accepted, but the php interpreter is frozen. In that case, there is nothing Cherokee can do but to deactivate the source.

--
Octality
http://www.octality.com/

_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

reidrac at usebox

Feb 18, 2010, 2:52 AM

Post #12 of 17 (1150 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

El jue, 18-02-2010 a las 11:28 +0100, Alejandro Barrera escribió:
> > [...]
> > Check this:
> >
> > http://www.fastcgi.com/archives/fastcgi-developers/2009-April/000230.html
> >
>
> Because this is happening a lot, maybe having an autospawn option might be a good idea ;) What do you
> think about it?

I think it's something I would put in the FAQ ;)

cherokee-admin is way cool, it could be interesting to include this in
the php fcgi conf part one so it's another option (although it's not an
cherokee issue, I guess it's a frequent issue because cherokee attracts
people from apache + mod_php and the move to fastcgi it's not as easy as
it seems at first hehe).

Regards,

Juanjo

--
jjm's home: http://www.usebox.net/jjm/
blackshell: http://blackshell.usebox.net/
ramble on: http://rambleon.usebox.net/

_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

abarrera at neurosecurity

Feb 18, 2010, 2:57 AM

Post #13 of 17 (1148 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

On Thursday 18 February 2010 11:48:02 Alvaro Lopez Ortega wrote:
> Cherokee does, in fact, spawn processes if needed. Basically, it launches
> a new process whenever it cannot contact the PHP interpreter (the
> connection is refused), that's a piece of cake. However, the tough
> scenario here is when the connection is accepted, but the php interpreter
> is frozen. In that case, there is nothing Cherokee can do but to
> deactivate the source.
>

Neat, you're right. Respawning in that case might lead to multiple frozen fcgi process :(

--
http://www.neurosecurity.com

"We must be the change we wish to see in the world"
Mahatma Gandhi
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

thebigslide at gmail

Feb 18, 2010, 6:34 AM

Post #14 of 17 (1132 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

Another catch is if there's an interpreter already listening and all the
interpreters' worker threads are busy - the interpreter will refuse the
connection and the spawn will fail because there's a process listening on
that port already.

Perhaps an option to send a configurable signal would be helpful. One could
then write a wrapper script to catch signal X and 'do stuff' - even if that
just amounts to logging that the administrator should be increasing the
number of interpreter threads.

So the logic could be if there's a live PID, send it the signal - if there's
no PID or the process has ended, respawn.

Ryan

On Thu, Feb 18, 2010 at 4:48 AM, Alvaro Lopez Ortega <alvaro [at] octality>wrote:

> On 18/02/2010, at 11:28, Alejandro Barrera wrote:
> > On Thursday 18 February 2010 11:22:27 Juan J." Mart�nez wrote:
> >> El mar, 16-02-2010 a las 03:47 -0800, Sz�sz Botond escribi�:
> >>> [...]
> >>> As for the minimal load, this is happening on my dev machine where only
> I
> >>> am using the webserver at a rate of about max. 10 request per minute.
> >>>
> >>> Ideas? Suggestions?
> >>
> >> Hi,
> >>
> >> How many PHP processes hare you spawning? If you have only one process
> >> for PHP (with children serving stuff), when the only one PHP process is
> >> busy you will get that error (if I recall correctly, I have the same
> >> problem at first).
> >>
> >> Check this:
> >>
> >>
> http://www.fastcgi.com/archives/fastcgi-developers/2009-April/000230.html
> >
> > Because this is happening a lot, maybe having an autospawn option might
> be a good idea ;) What do you think about it?
>
> Cherokee does, in fact, spawn processes if needed. Basically, it launches
> a new process whenever it cannot contact the PHP interpreter (the connection
> is refused), that's a piece of cake. However, the tough scenario here is
> when the connection is accepted, but the php interpreter is frozen. In that
> case, there is nothing Cherokee can do but to deactivate the source.
>
> --
> Octality
> http://www.octality.com/
>
> _______________________________________________
> Cherokee mailing list
> Cherokee [at] lists
> http://lists.octality.com/listinfo/cherokee
>

alvaro at octality

Feb 18, 2010, 6:50 AM

Post #15 of 17 (1138 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

Hello Ryan,

�Been there, did that..� :-)

Actually, it isn't that easy. There are quite a few additional cases to take into account.

For instance: the PHP interpreter may require up to ~5 seconds to get started (it's got a whole lot of dependencies to initialize). What would happen in a high load server? Let's suppose it takes 1sec to php-cgi to open the TCP port, and that your server has 100 hits/sec. It'd spawn 100 copies of php-cgi of which 99 would fail to initialize.

This is the current code (it isn't trivial to understand):

http://svn.cherokee-project.com/browser/cherokee/trunk/cherokee/source_interpreter.c
http://svn.cherokee-project.com/browser/cherokee/trunk/cherokee/spawner.c
http://svn.cherokee-project.com/browser/cherokee/trunk/cherokee/main.c#L345

Comments, thoughts and improvement proposals are always welcome!

On 18/02/2010, at 15:34, Ryan McIntosh wrote:

> Another catch is if there's an interpreter already listening and all the interpreters' worker threads are busy - the interpreter will refuse the connection and the spawn will fail because there's a process listening on that port already.
>
> Perhaps an option to send a configurable signal would be helpful. One could then write a wrapper script to catch signal X and 'do stuff' - even if that just amounts to logging that the administrator should be increasing the number of interpreter threads.
>
> So the logic could be if there's a live PID, send it the signal - if there's no PID or the process has ended, respawn.
>
> Ryan
>
> On Thu, Feb 18, 2010 at 4:48 AM, Alvaro Lopez Ortega <alvaro [at] octality> wrote:
> On 18/02/2010, at 11:28, Alejandro Barrera wrote:
> > On Thursday 18 February 2010 11:22:27 Juan J." Mart�nez wrote:
> >> El mar, 16-02-2010 a las 03:47 -0800, Sz�sz Botond escribi�:
> >>> [...]
> >>> As for the minimal load, this is happening on my dev machine where only I
> >>> am using the webserver at a rate of about max. 10 request per minute.
> >>>
> >>> Ideas? Suggestions?
> >>
> >> Hi,
> >>
> >> How many PHP processes hare you spawning? If you have only one process
> >> for PHP (with children serving stuff), when the only one PHP process is
> >> busy you will get that error (if I recall correctly, I have the same
> >> problem at first).
> >>
> >> Check this:
> >>
> >> http://www.fastcgi.com/archives/fastcgi-developers/2009-April/000230.html
> >
> > Because this is happening a lot, maybe having an autospawn option might be a good idea ;) What do you think about it?
>
> Cherokee does, in fact, spawn processes if needed. Basically, it launches a new process whenever it cannot contact the PHP interpreter (the connection is refused), that's a piece of cake. However, the tough scenario here is when the connection is accepted, but the php interpreter is frozen. In that case, there is nothing Cherokee can do but to deactivate the source.
>
> --
> Octality
> http://www.octality.com/
>
> _______________________________________________
> Cherokee mailing list
> Cherokee [at] lists
> http://lists.octality.com/listinfo/cherokee
>

--
Octality
http://www.octality.com/

_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

boteeka at yahoo

Mar 2, 2010, 3:44 AM

Post #16 of 17 (1066 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

This is for nginx / lighttpd but probably is valid for Cherokee too:
http://blog.taragana.com/index.php/archive/how-to-stop-crashing-hanging-of-php-cgi-spawn-fcgi-with-nginx-lighttpd/

----- Original Message ----
From: Alvaro Lopez Ortega <alvaro [at] octality>
To: Ryan McIntosh <thebigslide [at] gmail>
Cc: cherokee [at] lists
Sent: Thu, February 18, 2010 4:50:34 PM
Subject: Re: [Cherokee] 504 Gateway timeouts under minimal load

Hello Ryan,

“Been there, did that..” :-)

Actually, it isn't that easy. There are quite a few additional cases to take into account.

For instance: the PHP interpreter may require up to ~5 seconds to get started (it's got a whole lot of dependencies to initialize). What would happen in a high load server? Let's suppose it takes 1sec to php-cgi to open the TCP port, and that your server has 100 hits/sec. It'd spawn 100 copies of php-cgi of which 99 would fail to initialize.

This is the current code (it isn't trivial to understand):

http://svn.cherokee-project.com/browser/cherokee/trunk/cherokee/source_interpreter.c
http://svn.cherokee-project.com/browser/cherokee/trunk/cherokee/spawner.c
http://svn.cherokee-project.com/browser/cherokee/trunk/cherokee/main.c#L345

Comments, thoughts and improvement proposals are always welcome!

On 18/02/2010, at 15:34, Ryan McIntosh wrote:

> Another catch is if there's an interpreter already listening and all the interpreters' worker threads are busy - the interpreter will refuse the connection and the spawn will fail because there's a process listening on that port already.
>
> Perhaps an option to send a configurable signal would be helpful. One could then write a wrapper script to catch signal X and 'do stuff' - even if that just amounts to logging that the administrator should be increasing the number of interpreter threads.
>
> So the logic could be if there's a live PID, send it the signal - if there's no PID or the process has ended, respawn.
>
> Ryan
>
> On Thu, Feb 18, 2010 at 4:48 AM, Alvaro Lopez Ortega <alvaro [at] octality> wrote:
> On 18/02/2010, at 11:28, Alejandro Barrera wrote:
> > On Thursday 18 February 2010 11:22:27 Juan J." Martínez wrote:
> >> El mar, 16-02-2010 a las 03:47 -0800, Szász Botond escribió:
> >>> [...]
> >>> As for the minimal load, this is happening on my dev machine where only I
> >>> am using the webserver at a rate of about max. 10 request per minute.
> >>>
> >>> Ideas? Suggestions?
> >>
> >> Hi,
> >>
> >> How many PHP processes hare you spawning? If you have only one process
> >> for PHP (with children serving stuff), when the only one PHP process is
> >> busy you will get that error (if I recall correctly, I have the same
> >> problem at first).
> >>
> >> Check this:
> >>
> >> http://www.fastcgi.com/archives/fastcgi-developers/2009-April/000230.html
> >
> > Because this is happening a lot, maybe having an autospawn option might be a good idea ;) What do you think about it?
>
> Cherokee does, in fact, spawn processes if needed. Basically, it launches a new process whenever it cannot contact the PHP interpreter (the connection is refused), that's a piece of cake. However, the tough scenario here is when the connection is accepted, but the php interpreter is frozen. In that case, there is nothing Cherokee can do but to deactivate the source.
>
> --
> Octality
> http://www.octality.com/
>
> _______________________________________________
> Cherokee mailing list
> Cherokee [at] lists
> http://lists.octality.com/listinfo/cherokee
>

--
Octality
http://www.octality.com/

_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

stefan at konink

Mar 2, 2010, 3:50 AM

Post #17 of 17 (1064 views)
Permalink

Re: 504 Gateway timeouts under minimal load [In reply to]

Op 02-03-10 12:44, Szász Botond schreef:
> This is for nginx / lighttpd but probably is valid for Cherokee too:
> http://blog.taragana.com/index.php/archive/how-to-stop-crashing-hanging-of-php-cgi-spawn-fcgi-with-nginx-lighttpd/

Since there is a Lighttpd php thingie, why not use that?

Stefan
_______________________________________________
Cherokee mailing list
Cherokee [at] lists
http://lists.octality.com/listinfo/cherokee

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads