Very slow HTTP response times on AWS Beanstalk

0

I am moving 2 applications (using Django and Laravel) from Heroku to AWS Elastic Beanstalk hosting, but we are surprisingly facing x20 times slower response times when comparing the old and new infrastructures (no implementation changes at all) using postman (no proxy) and the client application on Chrome (the beanstalk application is behind a CloudFlare proxy for DDoS protections).

Here is an example of the latency difference on a live endpoint using postman:

Enter image description here

Enter image description here

We made sure that VPC and security groups, the assigned load-balancer, and the database are in the same region (Frankfurt), and nothing has worked out. We are using EC2 t3.micro instances, but we doubt that it is the problem because CPU usage didn't exceed 3% and memory usage also didn't spike at all during testing.

2 Answers
1

Thank you for providing these specifics. I'm curious to know whether this issue occurs intermittently or if it consistently takes more than 30 seconds to yield results. Assuming the current architecture follows a 'client - Cloudflare - ELB - application' pattern, an unusually prolonged 'Transfer Start' time could imply a delay in the 're-connection' to the ELB, more than what we'd typically expect.

If this is an intermittent issue, it's possible that one of the ELB nodes resides in a private subnet. This would cause a connection timeout when Cloudflare attempts to connect to the ELB node's IP within this private subnet. However, if Cloudflare subsequently attempts to connect to a different IP, it should then succeed. Could this potentially be the root cause of the problem? Read this document for further explanation.

Otherwise, diving into the Cloudflare logs should also shed some light moving forward.

AWS
weidi
answered 9 months ago
0
Accepted Answer

We made sure that the ELB node was within a public subnet within the VPC. The delay was noticeable consistently through all requests for both applications. The test we were conducting was using a PostgreSQL add-on database instance from a Heroku deployment in the eu region (our first demo was using the existing production database to test beanstalk app server workloads independently before shifting the DB as well to RDS in the next stage) under the assumption that the underlying EC2s were using the eu-central-1 region. After tracing the public Heroku endpoint IP address to find its location, it turned out to be eu-west-1 in Dublin, and it appears this was the cause of the issue

Thank you for your cooperation @weidi

answered 9 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions