EEUK2013

MySQL & ExpressionEngine

Why EEvolution?

We believe that system efficiency is #1 as its the root to saving time and costs

We provide cost effective solutions that have a return on investment

We create software to solve problems

Sound Familiar?

- Why is my site is slow?- How can I get better performance?- What if I get an increase in visitors?- Search bots are killing my server!

The database is the data store of your site... but what can you do to get the best out of it?

DESIGN FOR PERFORMANCE & SCALE

Hardware: Platform

Cost Performance Reliability

Shared Low Low Medium

VPS Low Low / Variable Medium

Cloud Medium Medium Very High

Dynamic Cloud Medium / PAYG Medium Very High

Dedicated High Very High High

Private Cloud Very High High Very High

Hardware: CPU

Cores (40%)

- Single, Dual, Quad, Six, HexClock Speed (30%)

- 2ghz, 3ghz, 4ghzVendor (20%)

- AMD vs Intel CPUs (10%)

- Single vs Dual

Hardware: Memory

25% of Server Memory should cover Database Indexes (not data in MyISAM)

- key_buffer_size = 25%-35% server memory

- PHPMyAdmin -> Status gives you a easy to read analysis and config recommendation.

- Check RAM benchmarks when purchasing a server

Hardware: Disk

IOPS & Random Reads - SATA (75- 150)

- SAS (140 - 210)

- SSD (9,000 - 10,000,000)

- RAMDisk (30,000 - 50,000, use with caution!)

Hard disks need a good controller which is also an important factor for performance.Never mix disk types in a RAID

Operating System

Background ProcessesLinux (LAMP, cPanel, Plesk, Webmin) - CentOSWindows (WAMP) - Windows XP - Windows 7 - Server 2008 + Core Mode - Server 2012 + Core Mode

Indexes

SELECT = ReadINSERT, UPDATE, DELETE = Read/Write

- Writes will always force an index update. - Only index columns that you will JOIN ON or use in WHERE and ORDER BY. - Schedule an auto DB optimisation. - EE thottling has a big impact on DB writes- Index files can be stored on a different disk.

Views, Stored Procedures, Functions

- VIEWS are used for organisation not for performance. They can improve speed due to reduced lock times on large datasets.- STORED PROCEDURES are used for organisation not for performance. Don't give up the dynamically created statement for the 'best practice' it'll cost you in time.- FUNCTIONS are used for organisation not for performance. Stay away, you will only slow down your queries and waste time.

Optimisation Maintenance

Automatically optimise your database with a frequently run Cron or Scheduled Task

- Tuning Primer Script- MySQL Tuning Script

Don't forget to email yourself the results.

Backup

Master / Slave, Replication- Backup, Distribution- Read only, Analysis (RAMDisk)Clustering, RAID- Resilience, Automatic FailoverCron / Scheduled Task- Custom Script, perhaps Amazon S3WHM- Scheduled Offsite Backup

So... we're firing on all cylinders!

Remember:

- Get best value hardware for your budget- Configure for the correct situation- Use PHPMyAdmin Status & Tuning Script- Ensure Backup / Replication / Resilience... Just in case, but always a must!

NOW LETS LOOK AT EE...

EE Settings

- Disable what you don't need

- Page, Template, DB, Tag Cache

- Config: Disable Tracking

Query Cache

EE Dynamic Query Cache:- If you do not use future entries, expiring entries and random entries turn this on.

- MySQL also has a cache mechanism which can improve performance by +200% when retrieving data from tables that do not change often. In general it has a 13% overhead. Set query_cache_size between 10MB and 150MB (avg size of query results * number of queries)

Schema

EE Schema- Entry data is wide not deep for scalability.- Relationships are centralised for simplicity.- Follow true relationships on your addons for best performance.- Index columns based on EE SQL Debug results. e.g. Searchable custom fields. Don't assume the schema is 100% efficient out of the box for EE or third party addons.

Pre-calculated fields

Do on-the-fly calculations in a dedicated field based on triggered events- Total number of sales- Total revenue per member- Total entry count per member or category

- Run a sanity check/update when idle to ensure this is accurate regularly.- Gives you the flexibility to COUNT (accurate, latency) or SELECT (possibly inaccurate, v.fast)

EE Entry DB Structure

Get Entries From Table - {exp:query sql=""}SELECT *, t.*, t.entry_id, COUNT(DISTINCT p.cat_name) AS distinct_count, CASE WHEN IFNULL(NULLIF(field_id_15,''),'none')='none' THEN field_id_16 ELSE field_id_15 END AS choice FROM exp_channel_titles tINNER JOIN exp_channel_data d ON d.entry_id = t.entry_idINNER JOIN exp_members m ON m.member_id = t.author_idINNER JOIN exp_member_groups mg ON mg.group_id = m.group_idINNER JOIN exp_member_data md ON md.member_id = m.member_idLEFT OUTER JOIN exp_category_posts p ON p.entry_id = t.entry_idLEFT OUTER JOIN exp_categories c ON c.cat_id = p.cat_idLEFT OUTER JOIN exp_category_field_data cfd ON cfd.cat_id = c.cat_idWHERE t.status='open' OR t.entry_id = (0{entry_id}) OR t.entry_id IN (0{preload_replace_vars}) OR t.entry_id IN (0{snippet_var}) OR p.cat_url_title = '{segment_3}' OR d.field_id_16 LIKE 'test%' OR t.entry_date > UNIX_TIMESTAMP('2013-05-16 00:00:00') OR d.field_id_16 = d.field_id_17 OR t.entry_id IN ({snippet_subquery_chosen_categories})ORDER BY t.entry_date DESCGROUP BY t.entry_id HAVING COUNT(p.cat_name) > 2

Summary

Remember:- Use this document as a reference- Plan your system resources, configure appropriately and use EE Debug Tools- Don't be afraid to use {exp:query} to get what you need.- Contact us if you need assistance in hardware or database decisions, optimisation or advice on your system... we're here to help.

Thank You !

Any Questions?

Tim MahoneyEEvolution Limited

info@eevolution.co.uk