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개 답변
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
답변함 10달 전
0
수락된 답변

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

답변함 10달 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인

관련 콘텐츠