Linux – TTFB on AWS EC2 Instance is Very Slow

amazon ec2amazon-efsamazon-elblinuxWordpress

I'm very new to hosting/server administration and my employer ask me to use this chance to learn and find a way to update our current hosting setup.

Our current setup was one EC2 instance that hosted multisite, it was being manage through Cpanel.

I did some research on AWS and this was new setup I'm trying to implement. On a high level this is the setup: We have a Load Balancer to round robin between two EC2 instances, the files for the website(s) is on a Network File System. The instances are also connected to a Relational Database. I might be over my head on this, but if there's a better solution please let me know.

Mini question on Load Balancer:

My Load balancer is listening on port 80 and 443. I added multiple SSL Certification into the https listener and it should be able to determine which certificate through SNI. Both of them are forwarding it to the same target group which the health check protocol is http. Something doesn't seem to sit well with me for this. If traffic come from port 443 connection wouldn't I just forward it to one of instance through port 80 instead of 443? It seem to be working for a very simple website (it just redirect to another website) though, so I didn't put too much thought on it.

This is the test result from I'm not sure on how to fix the TTFB given the ideal time is < 100ms where mine is 3036ms.

I think it might be because the EC2 instance I'm using now is the micro (free tier), so it might just be hardware issue. But given I only have one website running right now, I don't think this is an issue?

Or it might be because I've set the virtual host wrong?
I've setup a virtual host configuration file like so:

<VirtualHost *:80>
DocumentRoot /var/www/html/efs-mount-point/purpose-built/public_html
<Directory /var/www/html/efs-mount-point/purpose-built/public_html>
AllowOverride All

Any direction on how to tackle this issue would be appreciated.

Best Answer

So it turned out that my instance was at 90% steal time from the top command. Stopping the instance and rebooting it fixed the issue.

It's still slow, but is workable (down to 2.4 seconds)

Related Topic