Need help?

Our experts have had an average response time of 13.52 minutes in October 2021 to fix urgent issues.

We will keep your servers stable, secure, and fast at all times for one fixed price.

HTTP 504 error in CloudFront – How to avoid it?

by | Oct 27, 2021

Most often, to avoid the HTTP 504 error in CloudFront we set a higher CloudFront timeout value for the distribution.

Here, at Bobcares, we assist our customers with several AWS queries as part of our AWS Support Services.

Today, let us see how our Support Techs fix this error.

 

HTTP 504 error in CloudFront

Server timeouts are often the result of either an application taking a very long time to respond or a timeout value that is set too low.

However, before we set a higher CloudFront timeout value we need to address any performance and latency issues with the application and origin server.

Now, let us see the steps our Support Techs take to find performance issues and correct them:

  • Measure typical and high-load latency

Initially, we need to verify if one or more backend web application servers are experiencing high latency.

To check, we run this command on each server:

curl -w "Connect time: %{time_connect} Time to first byte: %{time_starttransfer} Total time: %{time_total} \n" -o /dev/null https://www.example.com/yourobject Note

In addition, our Support Techs suggest keeping in mind the following:

1) Though these values are relative to each application, a Time to First Byte in milliseconds rather than seconds or more is reasonable.

2) Even if the application latency under normal load is fine, viewers might still experience timeouts under high load.

To help prevent high-load latency issues, we check the server’s resources.

We run the following Linux command to check the memory Apache processes use:

watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"

3) High CPU utilization on the server can significantly reduce an application’s performance.

4) Other potential issues include database queries that run slowly when there’s a high volume of requests.

  • Add resources, and tune servers and databases

Once done, we need to ensure that we have sufficient resources in place for typical traffic and high load situations.

1) In the case of own server, it should have enough CPU, memory, and disk space to handle viewer requests.

2) On the other hand, if we have an Amazon EC2 instance as the backend server, the instance type should have appropriate resources to fulfill incoming requests.

In addition, our Support Techs recommend the following steps to avoid timeouts:

1. Suppose, the Time to First Byte value is high. Then we need to take steps to improve the performance of the application.

2. We have to tune database queries so that they can handle high request volumes without slow performance.

3. Also, we need to set up keep-alive (persistent) connections on the backend server.

  • If needed, adjust the CloudFront timeout value

Say, we evaluate and address slow application performance, origin server capacity, and other issues, but viewers are still experiencing HTTP 504 errors.

Then we should change the time specified in the distribution for origin response timeout.

[Need further assistance? We are always here for you]

 

Conclusion

In short, we saw the steps our Support Techs employ in order to fix the HTTP 504 error in CloudFront.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF