[Glass] Nginx , FastCGI and GLASS problem

[Johan Brichau]

Reading through your email again, since you say the fastcgi's are running correctly: can you leave out the try_files and make the / location pass on to the fastcgi directly?

I wonder if that would change anything.

Johan

On 26 Nov 2013, at 07:22, Johan Brichau <johan at yesplan.be> wrote:

> Mariano,
> 
> I would guess not all fastcgi gems are running correctly on all ports.
> There is a default timeout of 60s in nginx before it will pass a fastcgi request to another port in the upstream configuration. 
> 
> The reason you see the delay with the post and not with the following get might be because nginx is doing a round-trip load balance over the fastcgi backends and one request goes to a working port but the next is not (or vice-versa).
> 
> You might want to experiment by limiting the nginx conf to a single fastcgi backend and/or change the default timeout and put some logging code in your app when the request gets to seaside. That would at least allow to find on what to focus.
> 
> Johan
> 
> On 26 Nov 2013, at 00:33, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
> 
>> Also, when I see that 1-minute request in the browser development tools, it appears like 2ms receiving, 1 minute waiting...weird!
>> 
>> 
>> On Mon, Nov 25, 2013 at 8:26 PM, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
>> HI guys. This is the first time I am trying to use FastCGI. For some reason, i have a timeout with fastCGI.
>> I started the Gems either with:
>> 
>> 
>> WAGemStoneRunSeasideGems default
>>         name: 'FastCGI';
>>         adaptorClass: WAFastCGIAdaptor;
>>         ports: #(9001 9002 9003).
>> WAGemStoneRunSeasideGems restartGems.
>> 
>> (from GemTools) or from command line:
>> 
>> ./startSeaside_FastCGI 9001
>> 
>> In either case, what happens is that I can browse my app http:localhost:9001/dp (and 9002 and 9003). But when I do a request to the server trough my FastCGI, it takes ONE MINUTE to load the page. I am using Nginx in the backend with this configuration:
>> 
>>     upstream seaside 
>>       {
>>         server localhost:9001;
>>         server localhost:9002;
>>         server localhost:9003;
>>       }
>>  
>>       server
>>       {
>> 		  
>> 		listen 33300;
>> 		server_name localhost; 
>>         root /var/www/glass/;
>> 
>> 
>>   	  access_log  /var/log/nginx/fastCGI.log;
>>   	  error_log  /var/log/nginx/error.log info;
>>  
>>         location /
>>         { 
>>             try_files $uri @seaside;
>> 		  #  error_page 403 404 = @seaside;
>>         }
>>      
>>         location @seaside
>>         {
>>           include fastcgi_params;
>>           fastcgi_pass seaside;
>>         }
>>       }
>> 
>> 
>> Using the webtools of the browser, I see that each time I go to a page, there is either a GET or a POST that takes exactly 1 minute. I mean...nothing happens, until one minute passes and then the page is rendered. The requests are small.  And in fact, browsing directly to 9001/2/3 works perfectly. So I guess this is a one minute timeout of something.
>> 
>> For what I can see, it could be related to the 
>> 
>>  keepalive_timeout  65;
>> 
>> And in nginx error.log I see something like:
>> 
>> 2013/11/25 17:38:18 [error] 22835#0: *73 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET /dp HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "localhost:33300"
>> 2013/11/25 17:38:18 [info] 22835#0: *73 kevent() reported that client 127.0.0.1 closed keepalive connection
>> 
>> Any ideas what could be wrong?
>> 
>> 
>> Thanks!
>> 
>> -- 
>> Mariano
>> http://marianopeck.wordpress.com
>> 
>> 
>> 
>> -- 
>> Mariano
>> http://marianopeck.wordpress.com
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass