In this EngineSummit session, Mark Hout of Happy Cog will show you how to look under the hood and examine where EE is utilizing your resources. Check MySQL settings and Apache controls. Explore load testing options and see how much is too much. Walk away with a script that helps you identify where your pages are slowing down.
How to host a large scale EE site.
What is slowing your site down?
- The profiler - Always enabled during production. Forces you to not ignore the factors that are impacting your site.
- Benchmarks section - Base Classes (shouldn’t change).
- Controller Execution Time - is where your design comes into play.
- Total Execution Time - Sum of the above
- Memory Usage will never be 0
- Probably never lower than 3,000,000 bytes. If it jumps over 10 million, that’s an issue.
- Note memory at beginning and end of project.
- Biggest issue is loops and searches.
- Will never be 0. No queries, no site.
- Fact is, full featured applications need a lot of DB queries. If you were looking for two queries, look at a framework instead.
- Over or around 100, don’t be concerned.
- 200 - 300, that’s a red flag.
- Make notes and review during development.
- Tells the amount of memory and amount of time it takes.
- Parsing URL
- Watch for repeats or large jumps in time.
- Looking for similarities. Redundancies. Repeating patterns.
- Graphite to visualize the Template Debugger. Requires a slight modification to the core. Not a problem because if you overwrite it during update, end users will not notice. Makes template debugger easier to understand.
Testing against increased load
- Apache Bench - Load Tester using the terminal ab -n500 -c100 http://firebrand-media.com/
- C100 - 100 Requests at the same time
- Don’t do this to a live site! This can crash your site
- Siege - Install via Homebrew
- Looking for more requests per second.
- Siege and an actual browser request are very different
Optimizations: Front End vs Back End
- Reduce the number of requests
- Combine JS Files
- Combine CSS Files
- Cache headers
- Can have a drastic effect on performance. Example (~330K vs ~20K)
- .htaccess file sets headers
- Set expires active to on
- Set expires by type (CSS and JS lower - 5 Minutes, Images - 60 Minutes)
- Expired Default commented out.
- ETags usually commented out
The Back End
- Reduce Queries - isn’t as easy as you would think.
- Disable Tracking as a config variable - Considered high performance. Removed 5 - 10
- Disable Entry Joins by default and then turn it back on as you develop - disable=“categories, etc”
- Custom SQL - Last ditch effort. May be better off writing a custom query.
- Very Costly
- Use when parse order can’t accommodate you
- Use when passing EE variables to sub templates
- Don’t use when there’s no EE Tags in the sub-template
- Don’t use to keep your code DRY
- Like SASS for your EE templates
- Feels like EE
- Fast, compiled PHO
- Template inheritance, like Django
- Headers, Footers, etc are Twig templates
- Use when a site is getting really big. 20 - 30 designed templates.
Remove Embedded PHP
- Make a plugin
- Takes a second longer, improves performance by 30%
- Embedded PHP can’t be cached
- Consider Template Morsels or CE Cache
- Full page caches are difficult, but amazing
- Write ifs instead of else:ifs
- Dedicated database server - needs memory, hates interacting with the disk
- Dedicated web server - needs to interact with the disk, improve read times
- Have to set up a dynamic config file for EE
- Why is your site performing slowly? When is it performing slowly?
- mytop - http://github.com/jzawodn/mytop
- New Relic
- Pingdom - checks globally. Allows you to see the impact of redesign.
- Pingalytics - Compares Google Analytics and Pingdom