Frequent 504 Gateway Time-out on appharbor - appharbor

Deployed an asp.net mvc 4 app on appharbor with very low traffic. Each time the application is accessed after deployment of after a few minutes of inactivity, I get a 504 gateway time out error from nginx. Very annoying, what can I do to work around the error?
EDIT:
support ticket on appharbor's support site

The HTTP 504 is returned because the application doesn't respond within the request timeout. Application startup can take a little while, so sometimes a 504 may be returned on the initial request.
Applications on the free plan idle out after 20 minutes of inactivity. You can upgrade to one of the paid plans as they don't idle out after a period of inactivity.
We (AppHarbor) are working on decreasing the time it takes for applications to start up, which will mitigate the issue further. Note that the default request timeout was very recently increased to 120 seconds, so if you continue to experience this you're very welcome to open a ticket and let us know the application name so we can take a closer look.

Related

gateway timeout error "The gateway did not receive a timely response from the upstream server or application."

I'm getting an error of "gateway timeout. The gateway did not receive a timely response from the upstream server or application." What I'm doing is I'm getting data from sticky CRM by API and storing it into my database and it takes much time to execute. What I noticed is that I'm getting this error right after one minute. So I want to increase that time. I have install web server under ec2 instance and database under rds. I want to increase my gateway time from one minute to infinite or 15-20 minutes.
Help will be appreciated.
Thanks.

TFS 503 Service Unavailable when retrieving files

We have a TFS 2013 server which I use only for source control. I just got a new desktop PC with Windows 10 and Visual Studio 2017. I am able to connect successfully to TFS, and I can start to pull down code, but after the directory structure has been built locally and files start to come down, several are successful, then the rest fail with a 503 Service Unavailable, and the connection is lost, forcing me to reconnect.
I can connect again a few seconds later, and keep trying, and it happens again.
If I pull down files one at a time, it seems to be ok, but when I try to pull an entire project, it blows up.
This happens on multiple projects on the server.
In general, I see 503 errors in ASP.NET when I overload an application to the point where it crashes the application pool - I don't know if that's what's happening here, but if it is, I'm wondering if maybe VS is pulling down the code too fast, maybe with too many concurrent threads or something, that the older version of TFS can't handle, which crashes it.
If that's the case, is there anything I can do to change that on my machine? Or do you have any other ideas on what could cause this?
As of now, I don't have access to the server to grab the event logs, but I can put in a request if it's not something I can figure out and fix myself.
Last time I encountered this, I was behind a rate-limiting proxy. 503 is a common error code for temporary service interruptions such as rate limiting.
Excessive requests are delayed until their number exceeds the maximum burst size in which case the request is terminated with an error 503 (Service Temporarily Unavailable).
The IIS service that's hosting TFS can also be configured to have request rate limiting.
maxBandwidth Optional uint attribute.
Specifies the maximum network bandwidth, in bytes per second, that is used for a site. Use this setting to help prevent overloading the network with IIS activity.
maxConnections Optional uint attribute.
Specifies the maximum number of connections for a site. Use this setting to limit the number of simultaneous client connections.
Visual studio 2017 has optimized the way it downloads over multiple parallel threads (at least 8 if I remember correctly). This can trigger the rate limiting in some proxies. And lots of small code files can easily trigger a rate limit.
If it's possible to reach the TFS server directly, you could try to add it to the proxy exclusion list to rule out whether the proxy on your end is causing the interruption. But a HTTP server such as nginx could also be implemented as a security measure and may reverse-proxy on the server end, in which case the server admin must change the limits.
I had a similar issue when accessing our tfs-git repo from intellij. All of a sudden, it errored unable to access <repo url>. The requested URL returned error: 503".
What helped:
In intellij->VCS-git-> remotes change the url to a false one (validation fails) and then back to the valid one.
In my case a login request then appeared and I finally regained access to the repo.

Microsoft Bot (webchat channel): 500 Internal Server error: failed to send message

We have embedded a Bot on a web page through the web chat channel, if the Bot is idle for 10 minutes or so and then a question is asked, the Bot does not respond to it, however when the same question is asked again immediately it responds as expected.
On investigating the network capture, we observed the response received when the question was asked for the first time was 500: Internal Server Error with message as "failed to send message"
Are you running the bot in Azure? If so, make sure you have "AlwaysOn" enabled; otherwise the web app will be unloaded if it's idle for a period of time. Check this for a similar problem.
Always On. By default, web apps are unloaded if they are idle for some period of time. This lets the system conserve resources. In Basic or Standard mode, you can enable Always On to keep the app loaded all the time. If your app runs continuous web jobs, you should enable Always On, or the web jobs may not run reliably.
You can read more about the web sites configuration here.

Website Speed 'Connect Time'

After noticing a drastically slow load time on one of my website I started running some tests on Pingdom - http://tools.pingdom.com/
I've been comparing 2 sites, and the drastic difference is the 'Connect' time. On the slower site its around 2.5 seconds where as on my other sites its down around 650ms. I suppose its worth mentioning the slower site is hosted by a different company.
Thew only definition Pingdom offers is "The web browser is connecting to the server". I was hoping
Someone could elaborate on this a little for me, and
Point me in a direction of resolving it.
Thanks in advance
Every new TCP connection goes through a three-way handshake before the client can issue a request e.g. GET, to the web server.
Client sends SYN to server, server responds with SYN-ACK, client responds with ACK and then sends the request.
How long this process takes is latency bound i.e. if the round-trip to the server is 100ms then the full handshake will take 150ms, but as the client sends the request just after it sends the ACK work on the basis it's a cost of one-roundtrip.
Congestion and other factors can also affect the TCP connect time.
Connect times should be in the milliseconds range not in the seconds range - my round-trip time from the UK to a server in NY is 100ms so that's roughly what I'd expect the TCP connect time to be if I was requesting something from a server there.
See #igrigorik's High Performance Browser Networking for a really in-depth discussion / explanation - http://chimera.labs.oreilly.com/books/1230000000545/ch02.html#TCP_HANDSHAKE

What raises HTTP 503 and how to change timeout?

I have inherited an application (internal to my company) that uses javascript running in Internet Explorer which makes Ajax calls to a Struts-based application running in WebLogic Server v10.
Certain server-side operations in the system are taking longer than 3 minutes. Users consistently noticed that the Ajax call returns 503 error at the 3 minute mark. My users can wait longer than 3 minutes, but 503 errors interrupt their work.
This application needs to be performance tuned, but we badly need a temporary workaround to extend how much time can occur before a 503 error is returned.
The current theory is that the 503 error is being raised by the IE XMLHttpRequest object. A team of supposed WebLogic experts poured over our code and WebLogic logs, and declared that there's no timeout occurring on the server side. But I have my doubts.
My question is, which piece of software is responsible for raising 503 error: the browser, the Ajax javascript, or the server? And can this timeout period be changed?
A 503 error is kind of a catch-all for a lot of different types of errors, usually on the server side. In your case it could be that the server is just rejecting the connection after a certain timeout, and responding back with a 503 to indicate that the server is overloaded or cannot process your request.
A lot of times with web services, a 503 will be returned when the server code throws an exception or error. If the server code doesn't properly handle the error, it will bubble up to the server, which will just respond back with a generic 503.
http://www.checkupdown.com/status/E503.html
Error code 5xx (alternate definition)
RFC 2616
503 is a server error. XMLHttpRequest will happily wait longer than 3 minutes. The first thing you should do is satisfy yourself of that by visiting the problem URL in telnet or netcat or similar and seeing the 503 with javascript out of the picture.
Then you can proceed to find the timeout on the server side.
Your web server has a request reply timeout which is being tripped by long-running service requests. It could be the WebLogic server or a proxy. It is certainly not the client.
Have you considered submitting an asynchronous HTTP request that will be responded to immediately, and then polling another location for the eventual results? Three minutes is about 170 seconds too long.
503 is most likely due to a timeout on the server. If you can tune your Apache server, read about the Timeout attribute that you can set in httpd.conf.
Look in the httpd/logs/error_log to see if timeouts are occurring.
Refer also to this answer: Mod cluster proxy timeout in apache error logs .

Resources