Whether you’re a cash-strapped startup or an enterprise optimizing spend, it pays to run cost-efficient architectures on AWS. This session reviews a wide range of cost planning, monitoring, and optimization strategies, featuring real-world experience from AWS customers. We’ll cover how you can effectively combine EC2 On-Demand, Reserved, and Spot instances to handle different use cases, leveraging auto scaling to match capacity to workload, choosing the most optimal instance type through load testing, taking advantage of multi-AZ support, and using CloudWatch to monitor usage and automatically shut off resources when not in use. We'll discuss taking advantage of tiered storage and caching, offloading content to Amazon CloudFront to reduce back-end load, and getting rid of your back end entirely, by leveraging AWS high-level services. We will also showcase simple tools to help track and manage costs, including the AWS Cost Explorer, Billing Alerts, and Trusted Advisor. This session will be your pocket guide for running cost effectively in the Amazon cloud.
Watch the re:Invent recording here: https://www.youtube.com/watch?v=SG1DsYgeGEk
08448380779 Call Girls In Greater Kailash - I Women Seeking Men
AWS Pop-up Loft Berlin: Cache is King - Running Lean Architectures: Optimizing for Cost Efficiency
1. Cache is King
Scale Your Application while
Improving Performance and Lowering Costs
Constantin Gonzalez
Principal Solutions Architect
Amazon Web Services Germany GmbH
glez@amazon.de | @zalez
20. Browser Caching
Set max-age or expiry date in the headers.
HTML5 Application Cache.
Helps eliminate network latency.
But… Browser cache size is limited.
(e.g. IE is 8-50M, Chrome is < 80M, Firefox is 50MB, etc.)
22. Time to First Byte
68 ms
68 ms
68 ms
Client Server
136 ms
SYN
SYN/ACK
ACK,
GET /image.jpg HTTP/1.1
23. Bring the Bytes Closer to Your
Users 68 ms
Client Origin
SYN
10 ms
SYN/ACK
GET /image.jpg HTTP/1.1ACK,
GET /image.jpg HTTP/1.1
CloudFront
Saves 68 ms
RTT
SYN
SYN/ACK
Time to first byte: 20 ms vs. 136 ms
26. Edge Cache
How do you decide what to cache?
• Static or Re-Usable Content
• Customized Content
• On-Demand and Live Video
• Dynamic or Unique Content
27. Cache Static or Re-Usable Content
HTTP/1.0 200 OK
Date: Mon, 19 Mar 201 12:51:28 GMT
Server: Apache
Last-Modified: Mon, 19 Mar 2012 07:15:25 GMT
Accept-Ranges: bytes
Content-Length: 1918
Cache-Control: max-age=86400
Content-Type: image/jpeg
Vary: Accept-Encoding
Age: 16
X-Cache: Hit from cloudfront
Connection: keep-alive
36. Dynamic Content?
Zero TTL – cannot be cached!
CloudFront can still help…
TCP/IP optimizations for the network path
Keep-Alive Connections to reduce RTT
SSL Termination close to viewers
POST/PUT upload optimizations
Latency Based Routing
Low prices, same as static content delivery!
39. You can’t have dessert, until
you have your dinner!
-An Experiment.
https://secure.flickr.com/photos/stephen-oung/6319155216/
40. Experiment Premise
• Start with basic infrastructure.
– Single m1.large EC2 instance running Amazon Linux
– Single non-Multi-AZ m1.xlarge RDS MySQL 5.6 instance
– Apache httpd-2.2.25
– PHP 5.3.27
– Drupal Commerce Kickstart 7.2
– EIP on Instance
• Throw a ton of traffic at it.
– 8,000,000 queries, 40 per second, from 4 other instances.
• Profile it.
– New Relic PHP agent
– webpagetest.org
43. Web Cache
Webserver or proxy caches would live between
your CDN/Users and your web tier and can offer
up increased cost performance via reducing
internal application and database load. Can also
offer up increased edge to origin speed for lots of
content.
44. Web Cache
Popular solutions:
– Varnish
– Nginx
– Apache with mod_cache/mod_proxy
– Squid
– Perlbal
– Language/framework caches (i.e., APC, Zend)
63. Web Cache
• Opt for in-memory caching when possible.
• Pay attention to your cache hit/miss ratios. It could be a sign that you
need to re-size the instances or re-size the number of nodes in your
cache pool.
• Set smart TTLs so that you don’t affect new deploys or cache content
for too long.
• Be smart about what cookies can burst cache and what cookies can’t.
Don’t serve up other people’s content or stale dynamic pages.
64. Web Cache
How do you decide what to cache?
– All logged out user pages
– Any completely static pages
– Traffic/log analysis
• Look at your web logs/CDN logs
• Find heavily hit pages
• Figure out how often they actually change
• Apply a TTL to that page to be cached
– Even 60 second TTLs could help drastically!
66. Application Cache
Application level caches for information such
as session data, temporary application data
such as cart information, and live aggregation
of data feeds.
73. Application Cache
Use Cases:
– Session information
– Temporary data
• Cart info, metadata
– Rate limiting
• Fight abuse of APIs, spamming, functionality
abuse
– Counters
• Views, Scores, Leader Boards
74. Application Cache
How do you decide what to cache?
– Ideally, you have to treat data you cache at this
tier as loss tolerant if working with in-memory
caches.
– Session information that wouldn’t make sense in
cookies or in a true DB.
– Look at the kind of data your application is
generating and storing in a DB that it might not
need to.
76. Database Cache
Reduce workload on database servers by
caching commonly requested information, or
any information that might not change
frequently (i.e., user info, listing info, product
info).
77. Database Cache
Popular solutions:
– In-engine query caches
– Memcached
• On dedicated host
• On DB host (built in w/ MySQL 5.6)
– Redis
• On dedicated host
78. Database Cache
A word of caution:
In-engine DB caches are often not recommended for
many use cases, as they can significantly impact the
performance of many databases. Depending on the
workload and dataset you have, an in-engine query
cache might not be a good idea for you. We recommend
off DB caches where possible.
82. MySQL 5.6 + Memcached
RDS MySQL supports version
5.6 with integrated Memcached
on the instance:
– Part of the InnoDB engine
– Memcached running as part of MySQL
talks directly to data in InnoDB tables,
essentially turning MySQL into a fast
“key-value store”
– From the opposite view point, adds
persistence to Memcached
– Same Memcached API as standalone
https://dev.mysql.com/doc/refman/5.6/en/innodb-memcached-intro.html
84. MongoDB Queries
• Shut down 8 machines
Caching saves money
DynamoDB Reads
• Saved 3k reads per second
• (>20k reads per second in total)
85. Without negative caching
Cache really everything!
With negative caching
• Cache hit ratio 25-30% • Cache hit ratio 89-95%
Hit
Miss
86. AWS Marketplace & Partners Can Help
• Customers can find, research, buy
software.
• Simple pricing, aligns with Amazon
EC2 usage model.
• Launch in minutes!
• Marketplace billing integrated into your
AWS account.
• 1100+ products across 24+ categories.
Learn more at: aws.amazon.com/marketplace
90. Experiment Infrastructure (with cake)
• Added in ElastiCache Memcached
cache.m1.large
• Added in Amazon CloudFront for static content
– Tuned expires and cache headers in Apache
• Added in APC for PHP caching
– Increased memory to 128Mb, no other changes
• Did nothing to the DB
• Drupal memcached & CDN modules