Implementing High Performance Drupal Sites

Implementing High Performance Drupal Sites

View more presentations from Unimity

The Main Aspect covered during the Session:

1. What is “Performance”?
2. Different Layers of Performance
3. How to configure Drupal for Performance
4. Writing Drupal Modules for High Performance
5. Some Advanced Techniques & Caching Systems
6. Event Based Caching
7. Drupal 6 vs Drupal 7
8. 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.

Q: How do we show the dynamic content when we cache?

A: When we cache the content for a lifetime 10 mins, then your user will get the static content from cache for first 10 mins. After the expiry of the lifetime 10 mins, cache will be rebuilt and new content will be shown. If you don't want your user to wait for 10 mins to get the new content, then may choose from other available option is using Ajax to load the dynamic content considering the impact.

Three Cheers to Azri & IEEE, Drupal Camp Deccan was mind blowing fun!

At our Session on Performance

Drupal Soup & Drupal Socks

Dries lighing the lamp

Acquia Team walking down to Drupal Camp Deccan

Unimity @ Drupal Camp Deccan

Dries Keynote at DrupalCon London

Must listen to Dries Keynote at DrupalCon London. It is always great to hear him lead the Drupal Community!

He talks about Drupal and how it’s acceptance and usage has been increased. Drupal is now adopted more and more by Media, Government, Technology companies as a standard solution. He also highlights the way Drupal helps companies to innovate and move their interactions with their customers to a different level. Presents the summary of his State of Drupal 2011 survey, Drupal 8 and the way forward.


He highlights how opportunity should be the one that defines a products road map! The need for more marketing initiatives. Just jump in and watch Dries at London... I am missing being a part of it all!

Auto Complete form field with multiple Values

To create an auto-complete field in Drupal, all you need to do to is to use the From API attribute #autocomplete_path and associate with a custom menu callback that provides the AJAX response for the auto-complete field. The custom menu callback can define the query that needs to be made in the database before a result is returned. The below code can b used to create a multi-select auto-complete field.

The best examples of the auto-complete field in core are the author field in node create and edit and taxonomy auto-complete.

function my_module_menu() {
$items['my-module/my-autocomplete'] = array(
    'title' =>'My module autocomplete',
    'page callback' => 'my_module_autocomplete',
    'access callback' => 'my_access',
    'access arguments' => array('my module access'),
    'type' => MENU_CALLBACK,
  );
 return $items;
}


function my_module_autocomplete($string = '') {
  $array = drupal_explode_tags($string);
  // Fetch last value
  $last_string = trim(array_pop($array));
  $matches = array();
  if ($last_string){
    $result =  Define Query here... 
    while($obj = db_fetch_object($result)) {
      $prefix = count($array) ? implode(', ', $array) .', ' : '';
      $matches[$prefix.$obj->;name] = check_plain($obj->name);
    }
  }
 drupal_json($matches);
}


Reference:
1. Helper function taxonomy_autocomplete in taxonomy module
2. Function user_autocomplete in user module.

Working with Drupal’s hook_menu

Drupal’s hook_menu is one of the most important drupal hook. It defines paths in the drupal system and what they do. You can not write a custom module without understanding hook_menu. 

The functionality could be listing of content on the site or an administrative page or it could just be a special page that needs to be generated and maintained as a custom module, all these can be met by writing a menu callback. hook_menu is normally used in a custom module when using drupal’s page, views generated pages do not meet our custom requirements. 

Often we may not want to create new menu callbacks but may use functionalities provided by other custom modules menu callbacks. There may be a need to customize the menucall backs of core or custom modules to meet the requirements.

The below note gives an overview of the different usecases of hook_menu and also a peek in to how to alter a core/contributed menu callbacks in our own custom module.
The different usecases of a hook_menu 
1) Custom page or functionality on the site. e.g: Blog module’s callback blog_page that is Listing of all blogs on the site.

$items['blog'] = array(
   'title' => 'blogs',
   'description' => 'Listing of blogs.',
   'page callback' => 'blog_page',
   'access arguments' => array('access content'),
   'type' => MENU_SUGGESTED_ITEM,
 );

User modules’s callback admin/user/user. This menucallback lists users, provides for links to edit and add new users

$items['admin/user/user'] = array(
   'title' => 'Users',
   'description' => 'List, add, and edit users.',
   'page callback' => 'user_admin',
   'page arguments' => array('list'),
   'access arguments' => array('administer users'),
   'file' => 'user.admin.inc',

2) Generate Forms: All forms that are built in Drupal will have an associated menu callback. Forms that need beyond the node create and edit forms that are available with Drupal need to be built using page callback drupal_get_form. These could range from admin forms to user forms. Refer Form API for more information on building forms.

e.g: Node modules: create and edit content forms.
Contact module: Site wide contact form, user contact forms and Contact admin settings forms.

$items['admin/build/contact'] = array(
   'title' => 'Contact form',
   'description' => 'Create a system contact form and set up categories for the form to use.',
   'page callback' => 'contact_admin_categories',
   'access arguments' => array('administer site-wide contact form'),
   'file' => 'contact.admin.inc',
 );


3) AJAX callbacks: Any  AJAX  functionality on the site will have an associated callback that defines the action that happens or the value that needs to be retrieved on  AJAX .

e.g: user/autocomplete  AJAX callback that is called in used in the author field of the create and edit node form.

$items['user/autocomplete'] = array(
   'title' => 'User autocomplete',
   'page callback' => 'user_autocomplete',
   'access callback' => 'user_access',
   'access arguments' => array('access user profiles'),
   'type' => MENU_CALLBACK,
   'file' => 'user.pages.inc',
 );

4) Create RSS feeds

The hook_menu not only allows us to define other content formats that can be generated in response to a http request.

e.g: Node/blog modules provides for rss.xml callback that provides rss feeds.

$items['rss.xml'] = array(
   'title' => 'RSS feed',
   'page callback' => 'node_feed',
   'access arguments' => array('access content'),
   'type' => MENU_CALLBACK,

For  a full list of parameters that can be associated with a menucallback, visit hook_menu drupal 6 api page. Most importantly, in all the above the menu callback created can be associated with specific permissions. The access arguments help in defining the access rules and also in providing security to the menu callbacks.

Proper use of these parameters is important in implementing the functionality and also in organising the associated code.

Customizing core/contributed module’s menucallbacks
Some usecases include:

1. Rename the path of a core or contributed module. This can be achieved using: path_set_alias. 
path_set_alias('og/xxx/'. $node->nid, $alias_path);
This is particularly useful for modules that are not supported by pathauto. Path auto module provides for an admin interface to path alias various content in Drupal.

2. Reset some of the menucallback's properties by using Hook Menu Alter.

Removing user profile tabs using menu_alter
function my_module_menu_alter(&$items) {
$items['user/...']['type'] = MENU_CALLBACK;
} In the above example we are changing the type of Menu callback user/... from MENU_LOCAL_TASK to a regular MENU_CALLBACK. This callback will no longer be displayed in a tab.

menu_alter could be extended to change the access callback, redirect to another custom callback, etc.
function my_module_menu_alter(&$items) {
  $items['cart']['access arguments'] = array('access my module'); $items['cart']['page callback'] = 'drupal_goto';   $items['cart']['page arguments'] = array('my_module_menu');
} In the above example we reset the access arguments of the ‘cart’ callback in ubercart module to my modules permission 'access my module', redirect the cart callback to my modules callback my_module_menu.

References:

hook_menu api reference: 

http://api.drupal.org/api/drupal/developer--hooks--core.php/function/hook_menu/6

hook_menu_alter: 

http://api.drupal.org/api/drupal/developer--hooks--core.php/function/hook_menu_alter/6

Drupal's Menu System:

http://drupal.org/node/102338

Drupal and Mobile Apps

Today having a website is synonymous to being accessible in all devices. Drupal is being used as the backend Data store for a large number of Mobile Apps. Mobile Apps could be Iphone Apps, Anroid Apps or specifically for Blackberry.

The two modules that are being widely used in building Drupal based Mobile Apps are Services and View Data Source modules.

Services Modules

Services Module allows you to expose drupal data to external websites or Mobile applications. Earlier Services was used to integrate Flash with Drupal, today most of the use cases of Services module are for Mobile Apps, where Drupal acts as the backend. The power of services module is that it has multiple interfaces and hence brings with greater flexibility. The Programmer can focus on handling the content while Service takes care of the json response in appropriate format.

The Main components of the Services module are:

Servers: That Receive and Send requests
Authentication Layer
Services: These Process data that need to be pulled out of the Drupal backend

Link to Module Page: http://drupal.org/project/services

Views Data Source

This module allows you to render out put from various views in a variety of formats. The Module is extremely simple to use: Create a view as required, choose page display and one of the Views Data Source formats.

Link to Module page: http://drupal.org/project/views_datasource

Reference links:

http://www.lullabot.com/podcasts/drupal-voices-105-greg-dunlap-on-services-module-and-mobile-apps
http://www.lullabot.com/podcasts/drupal-voices-208-pat-teglia-on-developing-mobile-apps-with-titanium-framework
http://www.lullabot.com/articles/module-monday-views-datasource
http://chicago2011.drupal.org/conference/bof/mobile-apps-use-drupal-backend-w-services-modules-nysenate
http://groups.drupal.org/mobile

Interesting Facts on Drupal Module Development

I am reading Drupal 7 Module Development by

Matt Butcher, Greg Dunlap, Matt Farnia, Larry Garfield, Ken Rickard and Jon Albin Wilkins.

Inspired by the book, some Interesting Facts on Drupal Module Development that I wanted to share

1. What is the hook implementation in Drupal?
   EVENT Triggers in drupal: The Hook implementation is a function that follows a certain naming pattern in order to indicatie to Drupal that it should be used as a callback for a particular event in the Drupal System.
   
   In most cases ensure the hook implementations reside within the main .module file.

2. Placing your Custom modules:
   OPTION1: The convention that we follow is to place both Contributed and Custom modules under sites/all/modules directory. All the custom modules are placed with in sites/all/modules/custom.

OPTION2: The second approach could be to have all Contributed modules under
sites/all/modules/contrib and any Custom modules under sites/all/modules/custom. This may not be a good solution as in Drupal 7 when you use Drush, the modules are automatically installed under sites/all/modules.

OPTION3: The approach I read in the book seems really neat. Place all Contrib modules under sites/all/modules and all custom modules under sites/default/modules.
The main advantage being, it brings a clear separation between the modules maintained by us and those by the community.

But in the case of a multisite installation where there is a need to share the custom modules across installations choose OPTION1

3. The .info file in any module always starts with a $Id$. Have you wondered why?
   This is a placeholder for the Version control system to store information about the file. ( When the file was last checked in and by who)
   With the new GIT integration alive, this should be on the way out.
   
   
4. Follow Doxygen-style commenting (/**  */)
   @file decorator for doc-block should be the first doc block of any module
   Syntax: Begin with a single sentence Description of the module, followed by  a blank line and then followed by a one or more paragraph description of the module.
   ALL DOCS MUST BE WRITTEN IN GRAMATICALLY CORRECT AND PUNCTUATED SENTENCES.
   
   

5. 
   $variable = ‘This is a string’ ;
   t($variable) ;

   
   
   Why wouldn’t translation system work above?
   
   Automated Translation run, the code doesnot execute it only simply reads.
   
   
6. Once a module is installed, Drupal caches the content of the .info file. Revisit the module page to force Durpal to refresh this information.
   
   
7. Drupal arrays - terminate large multiline arrays with a comma: This is to help in avoiding syntax errors while adding or removing from a large array.
   This can not be extended to drupal js arrays.
   
   
8. 2 Most powerful Enhancements in Drupal 7
   
   
1. PDI – PHP Data Object library integration in Durpal 7: This  library is an abstraction layer that supports numerous database layer. This provides the capability for Drupal 7 to support beyond MYsql. Postgre-sql to Oracle and
2. Fields and Entities

                                                             i.      Field system: Bring with it CCKs functionality in the core

                                                          ii.      Entity System: make sit possible to define structures data types that are not NODES! 

Attending DrupalCon Chicago!

I have been working on Drupal projects for over 4 years now. Some high performance sites, some Durpal Applications and some others Content sites. I could talk about my Drupal experience professionally, about the features we implemented, the theming we did, the modules we developed, the performance tuning, etc. But now when I sit back now on my Flight to Newark and think about it, the most exciting part has been the Drupal Community!

When I retrospect about what I have been doing and why? What is it that has made me stick on to Drupal, work with Drupal and here fly across the world for a Drupal conference? The Answers are far beyond the challenges that I faced on a day to day basis or the bugs that I fixed in my projects or the technology I learnt. It is MUCH more than all this. It is my sense of belonging, being a part of this big community, sharing the success and the joys. The Feeling of Oneness!

In this respect I think the Drupal Community has made my experience in the last few years richer and just being a part of this one big community has given more joy.

I do not write modules, but I love participating in the Drupal Forums. I am very active in the Forums, most of the timesJ. Over the last year I was involved in QA of the Drupal redesign and early this year in bringing us all together for the Drupal 7 celebrations. I have also been very active in bringing together the Chennai Drupal Community.

The Chennai Drupal Community has been an exciting experience. Here our interactions have gone beyond the internet. We have regular face to face meetings with each other and share our experiences and knowledge in Drupal. The energy we share is humongous. I have also got a chance to present at many big conferences in India and to conduct Drupal Introductory training programs at Colleges.

Today, I am looking forward to meeting many fellow Drupaler across the world, who I have actively followed and some of whom I have interacted with! I am excited I will be meeting them face to face… Looking forward to meeting the Drupal Community.

We must have one DrupalCon in India every year, so all my colleagues, other Drupalers in India can share this experience…