Improved Website

The web-server configuration has changed yet again. It used to be highly available with scaling policies and everything but it came at a cost. First of all it carried a price tag, I was using AWS EFS to distribute the files to multiple servers. EFS is a great product but for my use it was also slow. The time to first byte was several seconds. I tried to improve this through memcached and NFS caching utilities but the lowest I got it to was 2.5 seconds to start serving the first byte. Now it is down to half a second and feels much snappier. It is on a single server now with backing EBS as the drive. I’m still running memcached on a seperate instance through AWS’s Elasticache offering. I’m really tempted to stand up an instance on Vultr or Digital Ocean to see how the speeds compare. I will be sure to post the results.

Moved to AWS!

This website is now being hosted on a cluster of servers within AWS. I definitely use this website as an excuse to learn more about infrastructure. I’ll post more about it soon, but currently we are fault tolerant. We are using two EC2 instances running apache, EFS holding the files, and an RDS instance running the database. This is behind an Application Load Balancer and the javascript and pictures are being served over CloudFront. It’s a little slow though for me, I’m trying to figure out why. If you aren’t logged in you’ll have a better experience. I’m gathering metrics on load times to help see what the story is.

SCript Race: Azure VS AWS

Let us compare the data I collected from both my scripts I made for AWS and Azure. Each script accomplishes the same things:

  • Deploy two Windows Server VMs from the providers official image repository
  • Deploy one internet facing load balancer with the two servers behind it on port 80
  • Use the providers built in orchestration method to install IIS and place a simple webpage in the root web directory
  • Validate the website is being served over the internet through the Load Balancer

Here is a comparison of the common tasks:

Here is a table of all the data:

TaskSecondsDuration in SecondsDuration in Minutes
Script Start00.00
Create Load Balancer14140.23
Create VM11761622.70
Install IIS On VM181664010.67
Deploy Website on VM1878621.03
Add VM1 to LoadBalancer954761.27
Create VM211151612.68
Install IIS On VM214853706.17
Deploy Website on VM21547621.03
Add VM2 to LoadBalancer1601540.90
Website Available160210.02
Script Complete (Total)1602160226.70
TaskSecondsDuration in SecondsDuration in Minutes
Script Start00.00
Create Load Balancer880.13
Create VM11570.12
Create VM22160.10
Assign SSM IAM Role on VM137160.27
Assign SSM IAM Role on VM24140.07
Deploy System Management Agent on VM11671262.10
Deploy System Management Agent on VM21701292.15
Execute Install IIS & Website On VM117220.03
Execute Install IIS & Website On VM217310.02
Add VM1 to LoadBalancer17520.03
Add VM2 to LoadBalancer17720.03
Website Available260831.38
Script Complete (Total)2602604.30
Certain tasks in AWS do not wait for their execution to complete. Checks were added in the script and the duration column indicates which were essentially run in parallel.

As you can see from the data above, in terms of automation AWS is much faster.