Things to consider when investigating / measuring site performance
CASE: single item view
FLEXIcontent has about same performance of item view regardless of site size, this is always a somewhat slower than Joomla's article view. But if you utilize some extra content / system plugins to achieve similar result in Joomla article view then the above may not be true.
CASE: multi-item views and item listing modules
(all multi-item views are rendered by category model/category template layout):
- multi-cats
- category (single category)
- author
- myitems
- favourites(upcoming v2.2.0) (now this view has a fixed template, cannot use FC category templates)
- tag (upcoming v2.2.0) (now this view has a fixed template, cannot use FC category templates)
* FLEXIcontent category view should be faster than Joomla's if you have more than 10,000 per category or per fontend view, or similar about 5,000 items, if not then reasons for not being are listed below:
- for smaller sites performace is anyway not issue (or enable Joomla DEBUG and watch the -difference- in seconds for the afterdispatch event, or better enable FLEXIContent performance stats to see it, see how below)
- Using blog template or FLEXIcontent Universal module with custom thumbnail sizes, result in heavy or UNEEDED phpThumb activity
- UNEEDED phpThumb activity:
default phpThumb cache size is TOO SMALL: (100MB), this will result in thumbs being kicked out of cache in large sites, thus considerably increasing CPU usage
-- Solution 1: set phpThumb cache size to 1GB or 2 GB or more
file:components/com_flexicontent/librairies/phpthumb/phpThumb.config.php
$PHPTHUMB_CONFIG['cache_maxsize'] = 100 * 1024 * 1024;
to 2 GBs
$PHPTHUMB_CONFIG['cache_maxsize'] = 2000 * 1024 * 1024;
(you need to restore this change every time you upgrade FC, future FLEXIContent version may have this in component configuration)
-- Solution 2: configured blog template or module to use a thumbnail already created by FLEXIcontent image/gallery field
- heavy phpThumb activity
Reason 1:
the original images are big e.g. 4 MBs,
-- Solution: please use smaller to achieve better performance, or use image field that allows fixed/precalculated thumbnails
Reason 2:
watermarking is heavy
-- Solution: please use smaller watermark and also small original images
- FACETED filtering is heavy in large sites with categories having >5.000 items
How to identify:
Enable performance display parameter in Component Settings/Options TAB, and do some repeated filtering in frontend category view
How to fix:
Disable FACETED Filter behavior in ALL or in some fields
- consider which filters need to count items per field value (=FACETED behavior = show item count next to every field value)
- you have 2 alternatives
a. set FACETED filtering to only count values for all category items (which is cacheable)
b. or disable FACETED filtering behavior (no item count next to filter's values)
- Creation of HTML for 1 or more field is not fast
if you have some custom developed fields then they may have some performance issue
How to identify:
Enable performance display parameter in Component Settings/Options TAB, and view some frontend categories
Does the total of some field show big values ? e.g. 0.5 seconds
How to fix:a. 3rd party field: Contact author of field, maybe this can be addressed with re-configuration of the field
b. built-in field: please post in our forums, asking if it is normal, maybe you will be asked for more information, also field creation will become costly if you try to show more than 200 items per page
- The time spent inside the category layout of the FLEXIcontent template is big, (this is called "template rendering" in the performance statistics)
- If your template a custom template, then compare performance with the FLEXIcontent template that you have duplicated, if differs a lot, consider what you have done in your custom template
- With FLEXIcontent (especially in frontend) you can always tell with part of your page creation is slow, just enable performance stats in frontend
(we are sorry that now these stats are printed along with data content, TODO move them to a file or together will hit URL or to other)
- Benefits of performance statistics included with FLEXIContent,
you can get measurements about how much these cost:
- How much Joomla 's Content plugins cost (+ Content events in System plugins)
- You can see that FLEXIcontent DB queries for item data retrieval have steady, (scale) excellently us your number of items per category grows
- Undentify if some fields are more costly
- you can decide to use or not FACETED filtering in all or some of your fields, this is always costly to do a DB-based way, see threads in drupal and in every DB-based implementation in any CMS, maybe in future we can have an APACHE solhr solution, or elastic search or sphix
- Undentify if your custom template is slow
e.g. if inside your custom template your are calling phpThumb, e.g. duplicate of blog template then read above about phpThumb cache
- see how other parts of FLEXIcontent page creation perform
NOTE 1: you can already use the fast caching (cache full page with Joomla cache plugin) but hits counting will not work, this will be address in v2.1.3 final or in v2.2.0
NOTE 2: we want to provide some real showcases of FLEXIcontent performance, ... coming with a video showcase that which you can follow and do yourself (although you will need a large (20,000 items) site to replicate the test)
NOTE 3: FLEXIcontent already caches all unchanged data,
e.g. FLEXIContent XML template parsing, but it is only done once and kept indefinetely until you clear cache
e.g. FACETED filtering per ALL item's of category (cacheable and recommended for large sites)
-- but we want to also support Joomla's progressive/convervative caching, (now not needed by FLEXIcontent but we understand the requests for compatibility)
About FLEXIContent basic / advanced search indexes:
these are a multiple-times faster to create than Joomla in large sites,
but their performance is slower than joomla in frontend, that is in the instant text auto-completion,
not in the search view items creations (search view has 90% performance optimizations as category view and as universal content module, v2.2.0 will finish work on it)