Yes, you should use fastcgi_read_timeout. You can find documentation here. According to that, you can specify this parameter either in http, server or location context. So it is also possible to put in into fastcgi.conf and include that file where you setup FastCGI.
I think I finally figured it out. The solution consisted in increasing the timeout values:
timeout connect 20s
timeout client 10m
timeout server 10m
I'm not sure why increasing client/server timeouts from 2 min to 10 min solved the issue. I believe it has something to do with keep-alive and the fact that HAProxy maintains open connections with S3/Node.
Nginx and Apache with the performant MPM-Event worker are using a dedicated daemon (service) to run PHP. You have already configured this daemon in the right way. But now you have to configure the web server to wait for such a long time. The magic setting can be done with the setting fastcgi_read_timeout.
Configure Nginx to wait some time ...
location ~ \....
Such behaviour is often caused by high heap memory usage and/or excessive garbage collection.
When Tomcat gets tight on memory it will start to respond slowly and timeout intermittently. Situation usually deteriorates slowly until it becomes unresponsive.
In such situations you may or may not see high CPU usage. Try to analyse memory usage (JMX may help ...
HTTP requests cannot live forever - either the server or the client will eventually give up (the most generous server-side timeouts for HTTP requests are usually 5-10 minutes, and users will frequently give up before then and start banging on the reload button - a virtually guaranteed way to kill your server).
Like Michael Hampton said, you need to redesign ...
It is the mail client problem.
There is related bug report on github. The developer said he did not consider it possible or necessary to implement HELO validation in this mobile mail client when sending SMTP, and clothe this bugreport.
There is proposed workaround - set up a mail server on the receiving of messages from clients on a port other than 25 (...
This looks like a problem with your app server, not nginx.
I'd say you're suffering from the proxy_connect_timeout - but this is set to 75
seconds which looks like a lot.
You may try to increase the value but the problem is probably elsewhere.
When testing the app backend itself, what does it mean you were able to "hit more than 1000 users"?
How did you ...
EC2 t2.micro instances are horrible. There, I said it. Horrible. If you're running a non-interactive application, and you don't mind if a certain job takes 10 times longer to run than it should, then t2.micros can work OK. For any type of interactive web application, though, they're worthless.
My guess is that if you'd watch top during the periods where ...
Figured it out!! It was giving 504 when curl tries to resolve to ipv6
On comparing the requests, the only difference was the ip address.
So I tried forcing ipv4 resolving via
curl -4 --head http://www.flipkart.com
and it worked!
You're using a Xen VPS with 1GB of RAM and 2GB of swap, and your VPS provider has the same ratio of RAM to swap for all other customers, including 256MB of swap for the 128MB of RAM for customers on the lowest tier.
That would seem like a very high swap to RAM ratio for a VPS hoster, especially if they offer low tiers like 128MB of RAM with 256MB of swap, ...