Upload
heath-dutton-
View
74
Download
1
Embed Size (px)
Citation preview
Our code connects peoplewith services they need
thedmsgrp.comheathdutton.com
Step 1 - Add a CDN
● Sign up for CloudFlare (or similar)● Typical settings
○ Auto-minify: HTML/JS/CSS.○ Browser Cache Expiration: 8 days.
● SSL settings○ SSL: Flexible (free SSL)○ Automatic HTTPS Rewrites: On○ Add a page rule: Always Use HTTPS○ Trap: Remove any http to https redirections in your
code to avoid redirection loops.
● Rate-limit your API○ Add limits to paths similar to page rules (beta)..
● Set up a staging environment (or two)○ Use the “Clone Environment” feature.
■ Use “Load balancing, auto scaling”, even if only one instance is needed.○ Copy the RDS instance separately.
■ Import data from production so that the weight of the data is taken into account.■ TRAP: If you let EB setup RDS for you it’s married to that environment..
Step 2 - Load Testing
Step 2 - Load Testing● Install NewRelic (everywhere)
○ Use .ebextensions○ TRAP: Keep your staging/dev environments in the Free Tier..
● Use BlazeMeter (or jMeter) for your baseline.○ Increase simulated users till failure.○ Compare this to NewRelic data from now on..
Step 2 - Load Testing
● Upgrade PHP$ eb platform select ; eb upgrade
● Configure PHP○ Opcache, APCu, etc.
● Experiment with caching engines○ File based, MySQL,
Redis, Memcached, APCu.○ TRAP: Shared caches WILL become a
bottleneck when scaling horizontally..
Step 3 - Optimize the Environment
● Find the bottleneck on a per-instance basis.○ Network○ Disk IO○ RAM○ CPU..
Step 4 - Scale Vertically
Step 4 - Scale Vertically
● Head over to ec2instances.infoto shop for a better fitTRAPS:○ smaller instances can be more costly than
large instances.○ “EBS only” instances may add latency if your
app needs to read/write to disks frequently.○ Burstable instances (like T2) are
counter-productive to auto-scaling.○ Unused RAM is wasted money..
Step 4 - Scale Vertically
● Switching your staging instance to a new EC2 type is quick and easy.○ No downtime (so long as you have 1 instance minimum for configuration updates)
○ Migrating RDS is a bit more involved..
Step 5 - Scale Horizontally● Set minimum and maximum
○ TRAP: “Minimum instances in service” for must be at least 1 if “Rolling”..
Step 5 - Scale Horizontally● Choose the tightest bottleneck as your scaling parameter.
○ TRAP: Using “Health” or “Latency” can be problematic..
Step 5 - Scale Horizontally● Use the “Immutable” deployment policy.
○ Health is checked automatically.○ Roll-backs are automated.○ TRAPS:
■ DB migrations taking more than a few minutes may abort a release.■ If you don’t use CloudWatch (or similar) your logs may be lost.■ Default limit of instances per region..
Step 5 - Scale Horizontally● Ensure CLI cron jobs only execute on one instance.
○ TRAP: You cannot use “Lead Instance” for cron jobs..
Step 6 - Optimize Databases● Experiment in staging with new indexes.● Use a replica database when possible.
○ Can be used to offload back-end processes or APIs that only need to be read only.
● Try upgrading the version, or a lateral move like MySQL to MariaDB..
Step 6 - Optimize Databases
● TRAP: Zombie queries!○ Connection count is limited by RAM of the RDS instance.○ One slow query can cause a cascade of locked queries, hitting your limit easily.○ Use MySQL Workbench to find (and kill) zombie queries.○ Set maximum values for interactive_timeout and wait_timeout to match your application.
(not 8 hours, which is the default)..
Step 7 - Optimize Code
● Trade XML/Yaml parsing for cache.● Find heavy transactions, and remove unnecessary loops..
Step 7 - Optimize Code
● Platform compilation (Mage / Laravel / etc)
○ Useful to test deployment success.○ TRAP: Custom code may break if not following the pattern of the framework.
● Optimize autoloader (Composer)
○ TRAP: Commit your composer.lock file, or compose before upload.
● Cache-Control wherever possible.○ Move more logic into javascript, so that HTML can be cached externally by the CDN..
Step 7 - Optimize Code
● Use internal cache engines often!● Wrap real-time database queries in
cache checks.
Step 7 - Optimize Code
● Use internal cache engines often!● Wrap real-time database queries in
cache checks.
● TRAP: Stampedes can still kill the site if you only cache AFTER the query is done.
Use “Egg” caching..
Your Results…● Can handle 1,200+ concurrent users (200,000+ daily visitors).● Hosting costs are down 60% (per user).● You have a plan:
Address the bottleneck, load test, Repeat....
Code sample: github.com/TheDMSGroup/laravel-eb