Basic performance application optimization techniques that can be applied to any application, from web to desktop or mobile, but with focus on php/mysql stack. How to identify bottlenecks and resolve them and what strategies to choose to avoid them upfront.
Live presentation:
https://www.youtube.com/watch?v=aas8oM7CLjk
2. ABOUT ME
A founder of a boutique web and marketing communications agency Drzno,
providing integrated communication solutions with focus on the digital
communication and website development.
Marketing communication strategies. Design. Digital communication.
4. ABOUT ME
• Organized 48 hours music festival featuring Guano Apes (German band
performing on MTV awards at the time)
• Published a poetry book
• Ran 3 consecutive political marketing campaigns. We won in all 3.
13. COMMON BOTTLENECKS
• Poorly designed database (Joomla permissions in JSON) and slow queries
• Expensive CPU operations: image resizing, calculations
• Expensive network operations: webservices, network disks
• Filesystem operations: even with SSD disks there will still be a significant amount
of latency
• All of the above inside a loop
14. ARCHITECTURE
Abstraction and flexibility are enemies of the performance
User interface, sofware interfaces, dependency injection, service layer, multiple
layers . The reason that each major Joomla release gets slower.
17. ARCHITECTURE
Execution trees – class that calls class.. and another ..and few another.
For each class file has to be loaded -> Anything that involves I/O operations is slow.
UI - data has to be stored somewhere, usually in DB – database lookups are much
slower than e.g. variables read from a config file on app initialisation.
Tradeoff between performance and flexibility.
18. ARCHITECTURE – DOS
UI only for user configurable options, file config for developer settings.
21. ARCHITECTURE – DOS
Parallel processing – yes, even in PHP.
Pthreads http://pthreads.org
http://docs.php.net/manual/en/book.pthreads.php
Using CURL to make parallel requests to php scripts :
https://github.com/marcushat/rollingcurlx
And since SOAP https://github.com/Meabed/asynchronous-soap
29. DATABASE AND QUERY
OPTIMIZATION
Query construction
• Reduce the amount of data selected in a query to only be what is required (i.e.
Type the "select" fields manually instead of using "select *")
• Don’t f.. store JSON in a relational database.
• Split complex queries into multilple calls
30. DATABASE AND QUERY
OPTIMIZATION
Indexes – the same as in a book. Index data is ordered according to order of columns
in create table - mysql knows where to look for data e.g. in a range from 5-10 or all
record starting with k.
• Indexes can make dramatic improvements
• B-tree indexes on columns found in WHERE, JOIN columns
• Leftmost column – MySQL can only search in it
31. DATABASE AND QUERY
OPTIMIZATION
Indexes – the same as in a book. Index data is ordered according to order of columns
in create table - mysql knows where to look for data e.g. in a range from 5-10 or all
record starting with k.
• Indexes can make dramatic improvements
• B-tree indexes on columns found in WHERE, JOIN columns
• Leftmost column – MySQL can only search in it
32. DATABASE AND QUERY
OPTIMIZATION
• Covering index – contains all data, not only conditional one
• Full text index – similar to search engines search, for MATCH operations
• Indexes are not used when optimizer determines result set will be too big
compared to all possible rows. Rule of thumb: 15-20%.
• In InnoDB you don‘t need to include pk in indexes, it is already included
• You might need to create indexes with same columns in different order
33. DATABASE AND QUERY
OPTIMIZATION
• Covering index – contains all data, not only conditional one
• Full text index – similar to search engines search, for MATCH operations
• Indexes are not used when optimizer determines result set will be too big
compared to all possible rows. Rule of thumb: 15-20%.
• In InnoDB you don‘t need to include pk in indexes, it is already included
• You might need to create indexes with same columns in different order
34. CACHING AND PRELOADING
Store already retrieved data for faster reuse. Can be combined with preloading
• It all boils down to selecting the right caching unit and cache invalidation.
Can be tricky – start simple and iterate - improve until you get the perfect result.
• Break execution cycle in smaller pieces
unless you are rendering a very simple page that generally doesn’t need cashing
at all, cache smaller pieces
• Best caching candidates
often reused data/processes and very expensive operations. Cache remote
resources whenever possible, there is no such thing as fast webservice.
• Choose memory based storage (Memcached, APCu etc).
35. CACHING AND PRELOADING
Caching types
• Variable caching
short lived cache that only lives during single execution cycle. Often used data is
stored in a (static) property
• J Method results caching
J implementation works fine for procedural methods or static methods, avaoid
with methods that depend on object property values. For those use J raw cache
(serialization?)
36. CACHING AND PRELOADING
• J Data caching
use J raw cache to store compiled datasets: queries, webservices
• J “auto” caching (view cache, cache plugin modules caching)
usable when application output only depends on URL parameters (non-
authenticated, no data from cookies or session).
• Http caching
server side, Varnish and similar, same rule as previous point.
43. CACHING AND PRELOADING
You should really use the internet some more..
Membership sites. Yes, in Joomla (not this one).
44. OTHER
• Use PHP 7: 40% faster
• Activate PHP opcode caching – reads files and compiles them to machine code,
without it script needs to be compiled each time. Built-in OpCache in php7 (Also
Wincache, Zend optimizer) or APC/Xcache for previous versions
• HHVM: J3.7. is compatible
• Server infrastructure: Database replication, load balancing, clouds etc.
