Online purchase Drupal 7 E-Books

Here are the list of some good e books if you want to purchase online. This books are really comprehensive and have significant in dept study materials which will help you to kick start your drupal 7 project and build professional websites in a minute.

Amazon.com have a great collection of drupal 7 e books. You can order them online or read offline. Just checkout the links for more.

http://www.amazon.in/Drupal-7-Bible-Ric-Shreves/dp/8126531436?tag=googinhydr18418-21

http://www.amazon.in/Drupal-Development-Example-Beginners-Guide/dp/1849516804?tag=googinhydr18418-21

http://www.amazon.com/The-Definitive-Guide-Drupal-7-ebook/dp/B005PYQGYU

http://www.amazon.com/Drupal-Module-Development-John-Wilkins-ebook/dp/B0057761UY


Go to amazon.com and there you will find more ebooks on latest drupal development techniques written by experts. 

Drupal 7 Useful Performance Tips

The below stated points are easy to implement if considered from the beginning of the development. By applying these simple guidelines a substantial performance improvement can be achieved for large Drupal 7 based websites which serves a lot of contents to bigger user base.

1. Use EntityFieldQuery to get data from database since it utilizes entity cache. This is faster than drupal db_query as it do not hit database server, rather than it uses cache tables / memcache.

2. Use AjaxBlocks to render the blocks/sections which should not be cached. This will improve the performance as most of the page will be served from cache. Also ajax request won’t affect page load.

3. While integrating Apache Solr Search, should avoid multiple calls to Solr on page load. Only one call should be made to Solr at page load, and all the other calls need to be fired via ajax after page load.

4. Avoid using views module for very complex displays to avoid unnecessary table joins from views. Develop these using custom codes and implement appropriate caching for these. Views module by default executes many queries which are executed in parallel with actual query which slows down the page execution. Views is good where a simple listing, grid, tabular data display with simple business logic. It is recommended to use custom code to generate the page where business logic is complex and need to alter views query operations.

5. If possible views litepager module can be used for better performance. If any pagination do not have link to go to the last page, there litepager can be implemented. This module is useful where the number of recordset is huge. This module bypasses traditional count query execution to determine total number of recordset which might be costly where there is large number of records.

6. Use varnish reverse proxy cache for anonymous users traffic. As anonymous users are expected to see static content, varnish can serve content directly from load balancer layer rather than hitting apache server and mysql server. Thus server load will be reduced for anonymous traffic.

7. If there are theme switching based on user location / device, then two different varnish cache needs to be configured for different domains (if two separate domain is used for each theme) otherwise have to configure varnish to detect request header at load balancer level.

8. Opt for responsive design rather than theme switching if possible. Theme switching is a conditional operation in drupal while the theme is needed to be changed based on the device. There is an additional overhead for caching functionality if varnish is used, as two different themes will be seen in same url. So it is suggested to use responsive design rather than theme switching for performance optimization benefits.

9. If same function is called multiple times in a page having same arguments, implement the usage of drupal static variables so that the function can early return the result during 2nd time calls onwards without executing the rest section.

10. Drupal Cronjobs should be running via drush. Drupal executes cronjob via drush with better memory management functionality than traditional cron.php execution which overheads apache php process in the server which might impact frontend users. Drush executes cronjobs in command line with separate php process which do not put load on the main php process responsible for generating drupal powered web pages.

11. Web service results should be cached if possible. Webservice is responsible for communication between two servers with different application. Frequently used webservices can cause slowdown a server as it consumes lot of resources (cpu,memory, network, I/O etc) to server data from one server to another server. Read-only web service data can be cached for certain amount of time having an expiry period so that web service will not be called again and again for same resultset reqested by the servers. Thus it also reduces the overhead of server resource utilization. If implemented, it is also to be noted that webservice cache needs to be cleared upon any change of provider’s data so that the consumer server will not get stale data from cache after data manipulation.

12. In mysql server, innodb_buffer_pool_size parameter should be according to the installed physical memory of database server (60-70% of size can be allocated for mysql). This parameter is mysql is responsible to pull the data from Disk to memory and send back that to requested application server. Increasing this parameter will result better performance if it is set to an optimal value based on server’s physical memory.

13. Use CDN or AKAMAI if possible for javascript, css and images only. Browsers can connect upto 4 domains for parallel download of static assets. CDN / AKAMAI provides separate cookie-less domains/subdomains for serving static assets of the webpages (js/css/images) . As a result, browser can parallel download static assets for faster page response.

14. Images should be properly scaled and compressed as per web standard. Force resize should not be done in tags. Images have specific compression rates while used for web pages. Images should be resized/scaled exactly same dimension as per html design. Otherwise, browser will spend extra time for downloading images larger than the standard size.

15. JavaScript and CSS should be aggregated, minified and gzipped. Drupal.org provides contrib advagg module to compress and minify javascript and css files with gzip format. This compressed static assets takes less time to be downloaded by browsers and saves around 80% of network bandwidth. Also number of http calls by browser is also reduced as multiple css and js files are combined into a single minified file during page rendering.

16. gZip compression in apache server should be turned on (apache mod_deflate module) to deliver compressed web pages to the browser to save bandwidth. Gzip compressed web pages have 80% less size rather than uncompressed pages. So pages will display faster in web browsers.

17. Small icons should be placed as a single css sprite image rather than multiple small images. An image sprite is a collection of images put into a single image. A web page with many images can take a long time to load and generates multiple server requests. Using image sprites will reduce the number of server requests and save bandwidth.

How to improve Drupal 7 Performance Using Content Delivery Network (CDN)

Drupal 7 allows developers to develop common functionality, layout and content in a much shorter timeline using off-the-shelf modules compared to developing such things from scratch. Also, due to a large online Drupal developer community, one can have ready access to latest modules, fixes and all manners of peer help, which makes it one of the most widely used Content Management Systems in use. 

However, the limitations of Drupal 7 become apparent as new contents, modules and themes are added since its performance is not optimized enough to handle module complexities. The most visible impact of the degradation in performance is an increase in the time taken for the website pages to get loaded. The de facto standard for page response times on most corporate websites is 5 seconds or less, failing which studies show that visitors are unlikely to return thus impacting the corporate’s image and business opportunities. This page lists some possible solutions for the performance issues in Drupal 7 so that the developers might benefit from the advantages provided by Drupal 7 without getting hampered by performance issues. 


Performance Improvement Recommendations for utilizing CDN Cache for Performance:

A content delivery network (CDN) is a collection of web servers distributed across multiple locations to deliver content more efficiently to users. The server selected for delivering content to a specific user is typically based on a measure of network proximity i.e. the server with the fewest network hops or the server with the quickest response time is chosen. It is observed that 80-90% of the end-user response time is spent downloading all the components in the page: images, style sheets, scripts, flash, etc. So it is always better to first disperse the static contents / asset files using CDN which can reduce the page response times significantly if is configured properly.

Benefits: For CDN implementation, a sub-domain is created and attached with a content delivery network service provider (Akamai, CloudFront etc) server to deliver the large assets like streaming media or downloadable files for the end users. In general, if the website URL is ‘www.example.com’ then ‘cdn.example.com’ is typically used for content delivery network implementation. The benefits are mentioned below -

1. Faster page response time

2. Cover maximum geographical barriers

3. Improved scalability

4. High availability based on the service provider SLA

5. CDN usage analytics / statics

Alternatives: For most of the content heavy sites Content Delivery Network is used to load different assets like documents, images etc. The CDN server (like Akamai) can cache full HTML pages for Anonymous users as well. This feature can boost performance for non-logged in users. By default Drupal7 provides form based login / logout feature using Druapl7 core user module which uses Drupal session based user permissions. To gain the benefit for authenticated user performance through CDN, the following approach can be considered -

1. A new socket based server is used to handle login / logout from external domain

2. Return the response with cookies in the browser to handle user permissions via AJAX i.e. no page reload

3. Only the dynamic part will be changed (new content will be fetched from the origin server)

4. In this way authenticated user will use the CDN cache for unchanged contents and the page load will be much faster.

Limitations: The below are the limitations of the above approach.

1. This is a costly solution as this needs both CDN and socket server to run the application.

2. Single point of failure if the socket server is down

3. Additional changes in the Drupal code will be required to run the application with this implementation.

Drupal have a nice module named CDN for integrating cdn with its static content (https://www.drupal.org/project/cdn). 

You have to download the CDN module for Drupal (version 2.5 or later). Install it like you install any other module for Drupal. After the module installation, go to admin/config/development/cdn (admin/settings/cdn on Drupal 6). There are three tabs:

1. General
2. Details
3. Other

I’ll cover them one by one. Note that you can install the Advanced Help module to get more and better help.

First tab: “General”

There is only one important setting here: the status of the CDNmodule. You can either disable it, enable it, or put it in testing mode, which is somewhere in between. In testing mode, none of your visitors will get files from the CDN; only users with the access files on CDN when in testing mode permission will get to see it. This is perfect to test whether the CDN integration is actually working correctly. So, for now, let’s put it in testing mode.

The second (and last) setting on this tab is the Display statistics setting. Users with the access per-page statistics permission will get to see, well,per-page statistics at the bottom of each page: “what percentage of files is served from a CDN”, and so on. Enable this for now, so you get to see the results for each page on your site.

Second tab: “Details”

At the top of this tab, there’s a Mode setting, which allows you to choose between Origin Pull and File Conveyor. Choose Origin Pull (the default).

Next, there are mode-specific settings. The most important one is the “CDN mapping” setting. Here we define which files are mapped to whichCDN (in case you’re using multiple CDNs — or static file servers).
Go back to the CloudFront Management Console and copy the domain name of your CloudFront Distribution. In my case: d67something714.cloudfront.net. Now paste this into the “CDN mapping” setting, but prepend it with http://. So your CDN mapping is now set tohttp://d67something714.cloudfront.net. This will cause all files to be served from CloudFront.

Read the included Advanced Help documentation to see what else is possible (e.g. serve images from a different CDN or only serve CSS and JSfrom a CDN), but for us (and for http://wimleers.com), this CDN mapping will do.

Third tab: “Other”

We won’t go into the details of the various settings on this tab, but there’s only one we care about for the scope of this article: the CDNsupports HTTPS setting. If your site is using HTTPS and you configured your CloudFront distribution’s Protocol Policy to Match Viewer, then you can enable this setting as well. Whenever your site is accessed throughHTTPS, your files will still be served from the CDN, via HTTPS!

CDN configuration

You're done!

If you haven’t already, make sure you have enabled Drupal’s CSS aggregation, block caching and page caching. The CDN module automatically rewrites image URLs in blocks and nodes, but we don’t want that to happen on every page load if it’s not necessary — hence enable those caching layers.