Last updated September 21, 2016. Created on August 10, 2012.
Edited by gaurishankar, VikrantR, ashish_nirmohi, hkovacs. Log in to edit this page.

Basic settings

  1. Configure cron job (for drupal 6 )
  2. Make sure all cache tables are clearing properly especially cache_form
  3. Enable cache options in performance page
  4. (For Drupal 6, )

Theme optimization

  1. Manually Remove blankspaces and comments from .tpl
  2. No indentation in .tpl
  3. Turn on CSS and JS aggregation in the performance page
  4. Manually reduce css file size by removing duplicate and combine similar together
  5. Move codes to functions which should be in a custom common module. Use functions for similar problems instead of coding separately. Refer core API

Coding standard and proper use of already existing core API


Secure codes


DB Query optimization in codes

  1. Join db queries whenever possible
  2. For Db update and insert, use core API
  3. Use drupal standard

DB table optimization


Disable unnecessary modules

  1. Devel
  2. Statistics
  3. Update status
  4. Use syslog instead of Database logging

Remove unnecessary contents and others

Cache modules

  1. Make use of Memcache module to reduce Database overhead ( ) Or
  2. APC (for drupal 7, )
    (for drupal 6, + (optional) )
  4. Some module may help improve (or )

    Make changes according to Google Pagespeed and yahoo YSlow suggestions

    MySQL Settings

    1. Cache Size say 32MB in MySQL

    Apache settings

    1. DNS lookup : OFF
    2. Set FollowSymLinks everywhere and never set SymLinksIfOwnerMatch
    3. Avoid content negotiation. Or use type-map files rather than Options MultiViews directive
    4. KeepAlive on, and KeepAliveTimeout very low (1 or 2 sec)
    5. Disable or comment access.log settings
    6. Enable mod_deflate or mod_gzip
    7. Install APC server with higher memory limit apc.shm_size = 64

    Also we can check this options :

    1) Turn Page Caching On

    What page caching does is that instead of using a bunch of database queries to get the data used in making a typical web page, the rendered contents of the web page are stored in a separate database cache table so that it can be recalled quicker. If you have 10 people visiting the site from different computers, Drupal first looks into the database cache table to see if the page is there, if it is, it just gives them the page. Think of saving the output of 50 separate queries so that is accessible with a single query. You obviously are reducing the SQL queries required by a lot. What the page cache table actually stores is HTML content.

    Page Caching is that it only works to optimize the page load time for Anonymous users. This is because when you are logged in, you might have blocks that show up on the page that are customized for you, if it served everybody the same page, they would see your customized information (think of a My Recent Posts block), so Drupal does not use the Page Cache for Authenticated users automatically. This allows you to turn Page Caching on and still get the benefit for Anonymous user page load times, but does not break the site for Authenticated users. There are other caching options that will help with Authenticated user page performance, we will talk about those later.

    To enable Page Caching, you go to Configuration | Development and select the checkbox next to "Cache pages for anonymous users".

    2) Turn Views caching on

    As mentioned when talking about Page Caching only working for anonymous users above, there are other caching options for helping with Authenticated user page performance. One of those options is to turn on caching for blocks and pages that you create using the Views module. This allows you to cache the output of the query used to generate the view, or the end HTML output of your View, and you can tune the cache for them separately. And realize too that this means you can cache portions of a page if you are using one or several Views blocks in the page, it will just cache that block in the page, not the whole page.

    See detail more info @

    See more @

Looking for support? Visit the forums, or join #drupal-support in IRC.


jaisenan’s picture

Thanks Serjas,
These tips are very helpful.

yngens’s picture

Quoting Locutus of Virtualmin project from

It would seem to me that the Drupal guys doesn't overly care about security, if they instruct users to apply the insecure FollowSymlinks everywhere.

They should be made aware of this potentially serious issue and make their software work with SymlinksIfOwnerMatch.

It would be nice if some kind of consensus over this controversial "SymLinksIfOwnerMatch" security thing would be arrived to.

jalilkhan’s picture