You are running a news website in the eu-west-1 region that updates every 15 minutes. The website has a
world-wide audience it uses an Auto Scaling group behind an Elastic Load Balancer and an Amazon RDS
database Static content resides on Amazon S3, and is distributed through Amazon CloudFront. Your Auto
Scaling group is set to trigger a scale up event at 60% CPU utilization, you use an Amazon RDS extra large DB
instance with 10.000 Provisioned IOPS its CPU utilization is around 80%. While freeable memory is in the 2 GB
range.
Web analytics reports show that the average load time of your web pages is around 1 5 to 2 seconds, but your
SEO consultant wants to bring down the average load time to under 0.5 seconds.
How would you improve page load times for your users? (Choose 3 answers)
A.
Lower the scale up trigger of your Auto Scaling group to 30% so it scales more aggressively.
B.
Add an Amazon ElastiCache caching layer to your application for storing sessions and frequent DB queries
C.
Configure Amazon CloudFront dynamic content support to enable caching of re-usable content from your
site
D.
Switch Amazon RDS database to the high memory extra large Instance type
E.
Set up a second installation in another region, and use the Amazon Route 53 latency-based routing feature
to select the right region.
B C E
2
0
sorry BCD
1
0
How are you coming up with these answers man?
0
0
I say BCD as E will not necessarily guarantee a 1.5second gain in the response times
0
1
BCD
0
1
A.
Lower the scale up trigger of your Auto Scaling group to 30% so it scales more aggressively. (scale up more servers will reduce latency because we will not allow the servers to to to a point of contention)
B.
Add an Amazon ElastiCache caching layer to your application for storing sessions and frequent DB queries (Ram is faster than ssd latency improver)
D.
Switch Amazon RDS database to the high memory extra large Instance type (running low on memory 2GB)
0
1
it says freeable memory is 2GB, it is not the RDS has 2 GB so B,C,E are best choices
1
0
A,B,D is correct
it could not be “C” as already in the question cloudfront is used
“Static content resides on Amazon S3, and is distributed through Amazon CloudFront”
0
1
C said cloudfront for dynamic content not for the static on S3
0
0
Can’t be D, instance is already of the highest size. BCE
0
0
B,C,E
0
0
BCD
0
0
BCE
Second installation means double the memory of RDS.
And the website has a world-wide audience.Latency based routing can reduce load time significantly.
1
0
I agree, BCD. Lower the scale up trigger is not going to help. Add an Elastic Cashing layer, Configure the Cloud Front – and update the Instance RDS type will.
0
0
BCD
A. This is probably not going to help… bottleneck is on the DB tier, not on the web/app tiers.
B. Correct, help the poor, bottlenecked DB out by front-ending it with ElastiCache.
C. Correct, why send traffic to your origin if you can just keep it at the edge? This may help out with web page load time latency all on its own, just by avoiding the backhaul from the edge to your origin alone. Also CloudFront has TCP windowing optimizations. The reduced load on your back-end bottlenecked DB on top of all of this is bonus.
D. Agree, the additional memory could help. The freeable memory is running at 2GB out of 16GB (m4.xlarge), meaning that there isn’t much available memory left (88% consumed). If you have some very large OLTP tables or very large processes, that may not be enough space to cache a very large table in memory or cache the process in memory. By not having those cached, you are forcing the DB to both do more work, and take longer to generate a reply because going to memory is much faster than going to disk or calculating an answer. The high memory instance (r3.xlarge) has 30.5GB of memory to work with. That could buy you enough space to cache more data in memory that might not fit today.
E. May help a very small amount, but probably not going to help much compared to the other answers. You’re already using CloudFront to cache at the edge, so that’s already going to reduce the bulk of the latency on your connections. If adding another region does help, it’s only going to be for data that CloudFront still has to reach back to the origin to get. And this option is going to double your costs. You could get more benefit for far less cost with the other answers.
3
0
Thank you
0
0
B C E
A- 60% CPU is just fine. 30% will not make any difference for the end user.
B- ElasticCache will help a lot offloading DB requests.
C- CF Dynamic Cache can help offloading the backend
D- Is wrong, DB memory is fine
E- will help for sure, double the infrastructure. it say WORLD WIDE site.
Never said anything about costs.
1
0
BCE,
D is wrong because ” While freeable memory is in the 2 GB
range”. So there is no memory contention
0
0
BCD
for A, even we set the 30% to scale out, the bottleneck is in the database side.So A out
E it doesn’t look like anything to do with average load time
0
0
Likely Answers
A –> NO. Since anyways Autoscale is configured I do not see a chance of performance improvement at 30% vs 60% both mean there is still enough CPU cycles available.
B –> YES. This is a no brainer
C –> YES. But I am not sure if Cloudfront can really accelerate dynamic content in the way define in this section.
D –> MAYBE. Possible that memory increase may decrease querry tine.
E –> MAYBE. The new updates every 15 minutes and we are assumming 100% of the data will be read , Cloudfront is already deployed and the reason for hitting the origin is only for dynamic data which cannot be cached. Having another region can gelp serve this dynamic data for global audience. On the flip side replication between the two DB needs to be ensured. Yo cannot have independent DB at both location as these may also store state information.
So tough between D and Ed
0
0
Correct is ABD
A. Scaling at 30% will keep the servers available to take on high load without much lag.
B. Elasticache will speed up the repeated read queries
D. DB has only 2gb Memory left. It is currently using extra large DB optimized instance. It may be better to switch to Extra Large memory optimized instance so that it has more memory available.
0
1
A-CPU
B-I/O
D-MEMORY
ALL THREE TAKEN CARE
0
1
BCD
0
0
On freeable memory, directy from amazon support:
https://forums.aws.amazon.com/thread.jspa?threadID=209720
The freeable memory includes the amount of physical memory left unused by the system plus the total amount of buffer or page cache memory that are free and available.
So it’s freeable memory across the entire system. While MySQL is the main consumer of memory on the host we do have internal processes in addition to the OS that use up a small amount of additional memory.
If you see your freeable memory near 0 or also start seeing swap usage then you may need to scale up to a larger instance class or adjust MySQL memory settings. For example decreasing
the innodb_buffer_pool_size (by default set to 75% of physical memory) is one way example of adjusting MySQL memory settings
Takeaway: extra mem is not going to help page load times here, but a 2nd region might. Keep in mind they’re going for a 66%-75% reduction in page load times – what if you added a region in Australia or HK, would that not help your worldwide users? rather than having traffic go to us-east.
Answer: BCE
1
0
B, C, E
0
0
I think C might be correct too because cloudfront does use geographical locations to determine which edge locationto serve requests from, doesn’t it? Therefore that can improve latency issues.
0
0