Turbocharging your extension // Joomla //

TURBOCHARGING YOUR EXTENSION © Klas Berlič & BzZzZ 2010

HOW IT ALL CAME ABOUT // How I got involved with cache //

Quite an amazing story of a willpower and turning a failure into a sucess with contributions to common good as a final consequence

In 2007 approached by a client to build travel portal for a client. No clearly defined business strategy, exact site scope was unknown Joint venture starting with visibility study

NOT AT ALL AN EASY TASK! especially if you look unimportant in the eyes of big players

2 Took 2 years

Only after then development finally began.

Vacations, Hotels, Travel and Airtickets booking management system html integration Already made airticket booking engine Website search box XML search CORE XML results Routing searches suppliers German Traffics Combining results Rendering results Tibet temporary booking Routing booking requests XML over XML static XML Booking request form XML Other SLO suppliers Traffics Tibet ADMINISTRATION Cosmo Palma Own inventory management Manual booking Bookings management

And then..

Development subcontractor left with only 10% done actual plan ..when we should have been at beta stage

If your partners fail, you have to do the job yourself. // Problem was I knew php only briefly //

3 // compare that to Joomla 1.6. :)) Learned php & OOP & brought it to ß level in 3 months.

End result

Probably one of the most complex and technologically advanced sites ever built on Joomla (it is simple..but in a Google way)

Combined power of Joomla php framework and ExtJS javascript framework used on a presentation layer

Results from own database merged with results from multiple different on-demand XML data sources Descriptions & images 1 Descriptions & images 2 Website search box XML search CORE suppliers German Traffics XML results Routing searches Tibet Combining results XML Rendering results temporary booking Routing booking requests over XML Own database Booking requests

Initially it took on average 45-65 seconds to perform a search & render results. Site badly needed a speed boost.

Speed?

Speed? // No, nothing illegal :)

Found an an answer in CACHING

JOOMLA! CACHE // explained //

How simple solutions can speed up things 10 times or more

CACHE Temporary store an unit of information to be reused later // a kind of digital recycling //

Multiple layers of web caching: Network (content delivery networks) Server (proxy servers, load distribution..) Daemons and interpreters – Apache mod_cache, Php – opcode caching, Mysql query cache application (Joomla cache) Web Customer (browser cache) - used by Joomla Page cache plugin

Web application caching creating temporary static copies of otherwise dynamic pages (or smaller data units).

Typical web site is displaying the same content over and over again No cache: everything has to be generated for each and every page view Caching: some or all of the information your code generates store in a cache object it when next user requests the same page or serve particular piece of information.

JOOMLA! CACHING TYPOLOGY & when to use each of them

template component modules functions smaller units page cache component module function/callback output cache view cache cache cache raw cache

PAGE CACHE

Takes snapshots of entire pages including everything - component, modules, plugins and a template. The widest and the least flexible approach of all caching options. // enabled by core system plugin -> site administrators choice //

MODULE & COMPONENT VIEW CACHE

A group as they they both create a static copy of complete output of a component or a module J1.5. Records based on the calling URL // UNSAFE, DOS // J1.6. Changes // more later //

Important difference // J1.5., changed in J1.6! // module caching can only be set on/off for all instances, can’t be controlled from within the module

Most widespread cache type, sometimes equaled with J caching in general. Performs well in the speed terms Disables any user<->extension<->framework interaction until a cached copy has expired Not suitable for any components or modules that react to user actions or render frequently changing content.

Side effect Cached copy includes only modules or components own output -> any external file that is called by using methods like $document->addStyleSheet() won't get included Workarounds performed to come around this limitations Catch22 Workarounds require computing time -> diminish the effect

FUNCTION / CALLBACK CACHE

The first of flexible caching types that enable us to differentiate between various parts of the extension and cache only those parts that are cacheable, while keeping dynamic parts uncached.

Caches results of function calls Records (cacheID) based on the arguments passed to the function

Often useful to cache model methods and keep views uncached. Example use Model performing expensive queries or similar operations is run only once to create a larger pool of data which is then further manipulated inside the view (sorting, pagination, calculations etc.)

OUTPUT CACHE

Caches output of some part od the script Records based on id passed

Basically output buffering with caching

RAW CACHE

Caches any data units Records based on id passed

Fully controlled by the coder – what, when to store, how to classify stored units (cache id). Highly useful when we are dealing with finite number of reusable data units

Example use High number of possible combinations of relatively small number of units – e.g. products in online store. No point to cache multiple parameter searches, cache each product separately. Other examples Expensive queries, remote XML, thumbnails, reusable texts or any reusable data set.

Also useful to pass large amounts of data between different parts of application (e.g. steps in click flow) Used in Joomla core: list of components, list of modules, menu tree, available languages, user groups, html renderers etc.

CASE STUDY travel booking engine

PROBLEM It took on average 45 to 65 seconds to display a search result

DIAGNOSIS Largest portion of time spent on remote XML requests, waiting for and receiving replies. Other two performance hogs were resizing images and internal database queries. 2nd and other pages of paginated results displayed instantly

Descriptions & images 1 Descriptions & images 2 Each result from badly designed primary XML paired with description and image that come from separate XML sources (one by one) Website search box XML search CORE suppliers German Traffics XML results Routing searches Tibet Combining results XML Rendering results temporary booking Routing booking requests over XML Own database Booking requests

Descriptions & images 1 Descriptions & images 2 SLOW Website search box XML search CORE suppliers German Traffics XML results Routing searches Tibet Combining results XML Rendering results temporary booking Routing booking requests over XML Own database Booking requests

SOLUTION Cache data on multiple levels: pages that were fully rendered - a lot of users Cache search with default parameters or click lastminute links, most just check one or two pages of paginated results XML queries (with longer lifetime). Pass data Cache from short results to detail pages Long-term caching of images and descriptions -> most important one

ALSO.. Add more indexes to Mysql tables Query and render images and descriptions per page: primary source queried once, secondary separately for each subpage (pagination).

RESULT Site runs 10 times faster Average first page loads in 5-6 seconds Subpages (paginated) load in 0.5 - 1 seconds Those timings further drop dramaticaly (50% or more) on peak hours, when most popular searches are returned from the cache. The bigger number of users on a site, the faster it goes. // within the hosting limits //

JOOMLA! 1.6. CACHE CHANGES // firsthand //

A very long story made short: "It finally works"

FRAMEWORK LEVEL Almost everyhing was redone under the hood. Cache library has been completely refactored.

Most important framework changes Cache handlers are now known as cache controllers (page, view, output, callback) Parent JCacheController was added - among other things it controls raw get and store calls.

New cachelite and wincache storage handlers (drivers). File cache handler heavily optimised All other handlers fixed with missing functions (gc, clean) added, their code cleaned and tested and should now be working properly. Semaphore locking was added for reliability and improved performance

Changed component view caching (replaced unsafe cacheID creation method) Module cache completely reconceptualized

CMS FRAMEWORK LEVEL CHANGES Caching implemented in all components and modules that can potentially gain from using it Caching added to some most expensive and frequent framework calls: JComponentHelper::_load(), JModuleHelper::_load(), JMenuSite::load(), JDocumentHTML::getBuffer()..

USER LEVEL FUNCTIONAL CHANGES Cache administration (Clean cache, Purge cache) now works with all storage handlers New standalone garbage collect script to be run from a crontab added libraries/joomla/utilities/garbagecron.php

API changes // and other changes important for developers //

COMPONENT VIEW CACHE Takes an array of url parameters and their types to create Cacheid. A replacement for a previous unsafe way which took the whole URL and so opened the doors for DOS attacks via random parameters/values added to request // Old cacheid created from URL retained for backwards compatibility if there are no $safeurlparams (to be removed in 1.7) //

Com_contact controler usage example: $safeurlparams = array('id'=>'INT', 'catid'=>'INT', 'limit'=>'INT', 'limitstart'=>'INT', 'filter_order'=>'CMD', 'filter_order_Dir'=>'CMD’, 'lang'=>'CMD'); parent::display($cachable,$safeurlparams);

MODULE CACHE 5 different modes of operation, 3 of them are to be set from module XML file, while 2 are meant to be used from within the module itself. Default is backwards compatible oldstatic mode that requires no changes to a module.

MODES TO BE SET IN XML Static - one cache file for all pages with the same module parameters Oldstatic - 1.5. definition of module caching, one cache file for all pages with the same module id and user aid. Default for backwards compatibility Itemid - changes on itemid change

In addition to cache field that was required in 1.5 there is now new hidden field called cachemode that sets any of the above modes. <field name="cachemode" type="hidden" default="static"> <option value="static"></option>

MODES TO BE CALLED FROM INSIDE THE MODULE: Safeuri - id is created from URL params array, as in component view cache Id - module sets own cache id's To use this modes rename 'cache' field in xml to 'owncache' field and call JModuleHelper::ModuleCache from within // actually a shortcut to cache callback to avoid code duplication in every module //

An example that uses safeuri mode and replaces uncached $list = modRelatedItemsHelper::getList($params) : $cacheparams->modeparams = array('id'=>'int','Itemid'=>'int'); $cacheparams->methodparams = $params; $cacheparams->method = 'getList'; $cacheparams->class = 'modRelatedItemsHelper'; $cacheparams->cachemode = 'safeuri'; $cacheparams = new stdClass; $list = JModuleHelper::ModuleCache ($module, $params, $cacheparams);

RAW CACHE Raw cache get and store are easily accesed by passing '' (empty string) as cache controller to JFactory::getCache Data is auto serialized / deserialized Locking & unlocking are performed automaticaly

AND HERE THE STORY ENDS // ok..a little more //

If you still remember how it all started.. I hope you like where it ended. // tried to do my best //

http://www.slideshare.net	50
http://www.bzzzz.biz	19

Turbocharging your extension // Joomla //

by kauselot on May 31, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 69

Statistics

Turbocharging your extension // Joomla // — Presentation Transcript