Basic Application Performance Optimization Techniques (Backend)

BASIC APPLICATION OPTIMIZATION
TECHNIQUES (BACKEND)
JAB 17
Klas Berlič Fras

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.

ABOUT ME
I try to do different stuff differently 

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.

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

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.

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.

ARCHITECTURE – DOS
UI only for user configurable options, file config for developer settings.

Design APIs to allow processing multiple items in a single call

ARCHITECTURE – DON‘T
Joomla Custom Fields and Tags

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

Delegate some work to the client.
 Clientside rendering: supply data, render in a browser

TOOLS
• Joomla debug output. Please use it.
• Xdebug profile + KCacheGrind (QCacheGrind for Windows)
• Z-ray http://www.zend.com/en/products/server/z-ray (there is plugin for Joomla)
• Blackfire https://blackfire.io
• PHPStorm

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

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

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

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).

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?)

• 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.

Preloading
Preload frequently needed data into memory e.g. on application initialization

Don‘t blindly preload all items.
For 1000 concurent users == 80 GB of RAM.

Not a realistic scenario?

You should really use the internet some more..

You should really use the internet some more..
Membership sites. Yes, in Joomla (not this one).

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.

Basic Application Performance Optimization Techniques (Backend)

More Related Content

What's hot (18)

Similar to Basic Application Performance Optimization Techniques (Backend) (20)

Recently uploaded (20)

Basic Application Performance Optimization Techniques (Backend)

Editor's Notes