504 Gateway Timeout
Table of Contents
This is caused by the load balancer being unable to obtain a request from a web server in a reasonable amount of time.
MageStack will interpret requests destined for the back-end (admin) or the front-end (customer) based on the MageStack-Area
header (see Debugging with response headers).
Default timeouts
Type | Duration |
---|---|
Frontend | 50s |
Backend | 7200s |
Common issues
Poorly written/slow PHP code
A front-end web page should load within 50 seconds, if not, its a major cause for concern. The target we set for "normal" performance is 0.2 seconds for the page to load, anything above that should be investigated.
We set the ceiling for load time quite high as standard, 50 seconds, for a number of reasons, an important one being the amount of time a customer would be prepared to wait (which from research is around 5 seconds). Poorly written code is the number one cause of bottlenecks and 504 errors for Magento and can be resolved through profiling the code.
Locked session
The most common cause of this error is a locked session. A feature of Magento is that when you load a page, it locks your session until the page load is complete. This can have the side effect that if you launch a very long running process (eg. a product import) - that your session will remain locked until that completes.
That could mean the site is completely inaccessible, in that specific web browser until the process completes. You can verify if this is the issue by opening the site in an incognito window. The solution in this situation is to run long-running processes by command line or scheduled task and not through a web browser.
Excessive traffic/high load
When your store receives more traffic than it can handle, it starts a process of requests queuing and waiting for their "turn". If you've got 8-Cores in your server, and you have 9 people request data, that means that the 9th person will need to wait until at least one other request has completed, so that their request can be processed.
If your resources are saturated, it will mean that load times will increase and requests will start to queue and backlog. Ensuring you adequately prepare for a high traffic situation is essential to preventing this scenario. Contact our support team if you want assistance in planning a high-traffic promotion.
Blocking requests
There are a few layers peripheral to Magento where delays can creep in, those being delays incurred when connecting to external services.
A locked SQL table/row will cause all other PHP processes to stall, causing queuing to occur until the lock is released. Common causes of row/table locks are reindexing during production hours, where the locked reindex process will make client requests wait until it is complete.
Delays from 3rd party services can also cause queuing to occur. Common causes of this are blocking CURL requests to external web sites, like external search, reviews, checkouts or even licensing checks from modules you have installed. Unfortunately, if a 3rd party service that your store depends on is down/slow - it means that your store in turn will go down/slow.
Incorrectly tagged traffic
Magento uses a default admin URI of /admin
- if this URL is changed, the MageStack-Area
is misclassified and requests destined for the back-end are treated as front-end requests; subject to lower timeout windows, lower PHP memory limits etc.. This will cause undesirable side effects.
Whenever the admin URI is modified, MageStack's configuration needs to be modified to suit your change. At present, only a member of our support team can make this change for you.
Prior to SUPEE-6788, third party modules for the admin did not use the standard Magento URI structure, but instead have custom URIs that are indistinguishable from those in the frontend. Again, an exception has to be defined in MageStack to ensure that these requests are appropriately identified.