The Main Aspect covered during the Session:
- What is “Performance”?
- Different Layers of Performance
- How to configure Drupal for Performance
- Writing Drupal Modules for High Performance
- Some Advanced Techniques & Caching Systems
- Event Based Caching
- Drupal 6 vs Drupal 7
- Performance in Drupal 8
Questions Asked after the Session:
Q: Why did you use Panels for the Deccan Chronicle Home, though Panels could be a performance hazard?
A: Panels with the support of Ctools provides us many features to build a page or mini panel with drag and drop, create own layout, etc. These abstractions/features make panels a heavy module to use. Yes absolutely true, but we need to balance user experience and requirement with performance. Hence Panels was to give better user experience to the Editor who manages the site. Being aware of the implication on performance, we planned the cache very effectively by using time based (tradition) and event based cache clearing systems. We enabled the cache in all panes and pages in the panels.Q: Is Boost a good option?
A: Boost is a good option for anonymous users and hosting is in shared environment, where you will not have option to install other advanced cache support modules like memecache or varnish. Boost will serve the cached static html files for the configured cache lifetime, once the lifetime expired static html page will be regenerated. When we compare Boost and Varnish, Boost caches the content and delivers it without disturbing MySql. Varnish works at a layer above Apache. Another difference is Boost uses the file system (disk) where as varnish uses RAM. Refer http://groups.drupal.org/node/46042, http://cruncht.com/95/drupal-caching/. The benchmarking helps to decide that varnish is better than Boost. As the time old concept RAM is faster than Disk. So if you have infrastructure to install Varnish then Varnish is the better option.Q: Writing custom query to get required information from node vs using node load
A: This question was in many of the developer's mind. node_load is a function which loads or constructs the node object by querying the database. This function uses static variable so if the node object is constructed once, then from next time it will be serving the node object from the static variable (static variable life time only limited to a single page load). Now we see how to decide on node_load or querying the table, this is depends on the use case I suggest. The Answer is written with Drupal 6 in mind.In a page if you want to list ten other titles written by the author of the node we are viewing, then go for Querying the table. This is because we only need to query a single table to get this information. Node load will be a overhead, considering there will joins with the node revision table, CCK fields table.
In other case you want to display list of node snippets (set of fields like title, teaser, date of node, configured fields etc. ) In this case we should use node_load, because node_load not only loads the node object from the database, it runs required on the node object. Some examples could be alternation in the teaser length or changing the date format etc.
Q: Do we use cache_clear_all() or clear the cache based on CID?
A: While writing code to clear the cache in our module always prefer to call Cache_clear_all by passing the CID and table name, by this only the cache content of the CID in the table will be get cleared. Or if you want to clear many rows you may use the wildcard option provided in the function.. In other case if you call cache_clear_all without CID and table, all expired cache content from cache_block and cache_page tables will get cleared (In case you have not assigned minimum cache lifetime then all temporary cache will get deleted). If you are storing the cache in other tables it is required to specify the table name.We used this concept while creating event based caching system with in our application.
Note: Use Cache_clear_all() with out arguments only if required, as if not used properly it may defeat the purpose of caching.
