EEvolution slides from EEUK2013 to use as a reference to our talk. Let us know if you need a hand with anything or further explanation... we know it was quite a heavy presentation.
2. 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
3. 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
4. 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
5. Hardware: CPU
Cores (40%)
- Single, Dual, Quad, Six, Hex
Clock Speed (30%)
- 2ghz, 3ghz, 4ghz
Vendor (20%)
- AMD vs Intel
CPUs (10%)
- Single vs Dual
6. 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
7. 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
8. Operating System
Background Processes
Linux (LAMP, cPanel, Plesk, Webmin)
- CentOS
Windows (WAMP)
- Windows XP
- Windows 7
- Server 2008 + Core Mode
- Server 2012 + Core Mode
9. Indexes
SELECT = Read
INSERT, 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.
10. 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.
11. 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.
13. 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...
14. EE Settings
- Disable what you don't need
- Page, Template, DB, Tag Cache
- Config: Disable Tracking
15. 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)
16. 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.
17. 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)
18. 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 t
INNER JOIN exp_channel_data d ON d.entry_id = t.entry_id
INNER JOIN exp_members m ON m.member_id = t.author_id
INNER JOIN exp_member_groups mg ON mg.group_id = m.group_id
INNER JOIN exp_member_data md ON md.member_id = m.member_id
LEFT OUTER JOIN exp_category_posts p ON p.entry_id = t.entry_id
LEFT OUTER JOIN exp_categories c ON c.cat_id = p.cat_id
LEFT OUTER JOIN exp_category_field_data cfd ON cfd.cat_id = c.cat_id
WHERE 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 DESC
GROUP BY t.entry_id HAVING COUNT(p.cat_name) > 2
19. 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.
20. Thank You !
Any Questions?
Tim Mahoney
EEvolution Limited
info@eevolution.co.uk