How to Build High Performance : WordPress
•
0 likes•549 views
How much traffic can your WordPress website handle? Find out your traffic capacity, how to build scalable infrastructure easily on Amazon Web Services and how to load test your final product.
Recommended
More Related Content
What's hot
What's hot (19)
Similar to How to Build High Performance : WordPress
Similar to How to Build High Performance : WordPress (20)
Recently uploaded
Recently uploaded (6)
How to Build High Performance : WordPress
- 5. • 1% loss in revenue per every 100ms of delay • Abandonment begins at 3 seconds • Latency noticed in as little as 500ms
- 7. Portfolio Support “I Create Beautiful Websites” Mobile Friendly Googable problem solving No wheel re-inventing
- 14. • Generally non-technical. (Easy to edit and create) • Wide variety of fluid business needs • Wants support and documentation for the life of their business.
- 16. Pointless • Traffic capacity given in days or months • The word “Unlimited” • Spending your way to performance without optimization
- 17. Credit: KM-Artwork, Deviant Art
- 22. Linux Apache MySQL PHP Apache • PHP is attached to every request • .htaccess is never cached • Limited asset and content caching options
- 23. Linux Enginx MySQL PHP Nginx • Only serves files (and it does so quickly) • No .htaccess • MicroCaching
- 24. Linux Enginx MySQL PHP • OpCache since 5.5 • Separation into dev, stage and live pools • Simpler scaling PHP-FPM PHP
- 25. Linux Enginx MySQL PHP MySQL • Heavy Machinery (Slow) • Consumes valuable resources • Little to be gained from config tweaking
- 26. Separation of MySQL • Web server and MySQL no longer fight for resources • Scaling (and cost) is more focused • Failover, read-replicas, restoration and logging are exposed to the infrastructure as code layer.
- 27. MemcacheD • Deliver key value pairs with superiors speed • Relieves relational database of traffic. • Rebuilds itself upon failure.
- 28. Isolated Application Volume • Scalable performance dedicated serving PHP. • Cleaner snapshot and restoration. • Simplifies cloning for scaling or debugging. • Makes websites “Portable”. Drives can be assigned to account permission for client transfer.
- 29. S3 Bucket Essentially an enterprise grade, internet connected NAS • Effectively infinite storage • Dynamically adjusts to meet traffic demands • Easily attaches to a CloudFront Distribution
- 30. CloudFront Distribution The most important performance improvement • Relieves your web server of traffic • Serves from (much) closer to your user • Clusters of servers optimized for static delivery, built for traffic.
- 31. Basic High Performance Infrastructure • 12 month free tier compatible. • Easily scaled. • Easy to build (with bAWS).
- 32. A More Complete Picture
- 33. Route 53 Features • Low TTL defaults • Supports complex routing • Supports alias records What is it? DNS servers. Replaces the “ns1.example.com” and ns2..” servers you receive from most hosts Provides 4 geographically diverse DNS servers on the edge network.
- 34. EC2 (T2 Server) What is it? Your web server • Baseline performance standards • CPU credits create measureable performance expectations (i.e. “Noisy Neighbor” solution) • CPU class transparency Free Tier: t2.micro 1CPU 1GB Ram
- 35. EBS What is it? Your hard drives(s) • Performance transparency per drive size • Purchasable, guaranteed performance options • Each provision stored redundantly in multiple locations. • Snapshots have account permissions for easy, secure transfers Free tier: 30GB Storage per service
- 36. CloudFront CDN • PersistentTPC Connections • No performance tiers • Same network as enterprise clients, even for pennies a month
- 39. • W3 Total Cache • Dynamic (Memcache Based) Caching Available • Poor CDN Support • Requires removal of all other caching • WP Super Cache • Simple CDN Support • Relies on heavily on hard drive. • Bat Cache • Simple setup. Doesn’t interrupt other systems.
- 40. Benchmarking • WebPageTest.org • Apache Bench • Bees with Machine Guns
- 41. Apache Bench ab -n 100 -c 10 http://rr.digitaldev.io/
- 42. Apache Bench ab -n 100 -c 10 http://rr.digitaldev.io/ • Number of hits to send
- 43. Apache Bench ab -n 100 -c 10 http://rr.digitaldev.io/ • Concurrency of the hits. This is the metric which matters
- 44. • Requests Per Second • ~95% Request Mark Important Metrics Keep increasing concurrency until the 95% mark surpasses your response threshold (around 200ms). Note: Without cache, heavier concurrency caused connection refused errors, which showed increased performance, with log errors the only indications of failure
- 46. SuperCache 100 Concurrency Still holding up
- 47. SuperCache 500 Concurrency Starting to unravel
- 48. SuperCache 1,000 Concurrency Completely unacceptable
- 49. WebPageTest: New York Before CDN After CDN
- 51. WebPageTest: London Before CDN After CDN
- 52. Bees with Machine Guns bees up –s 10 –g Bee –k bee.pem bees attack –n 10000 –c 1000 –u http://rr.digitaldev.io
- 53. Direct to Server Servers in N. Virginia attacking Oregon 2 Second response time indicates high likely hood that connections were refused
- 54. Behind the CDN Servers in N. Virginia attacking Oregon behind CloudFront Over 2x the requests per second. 420ms response time is slower than ideal, but keeps users happy.
- 55. • Nginx micro caching • Varnish • CDN HTML delivery • Load Balancing