![Presentation Path ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (18)
Destaque
Destaque (14)
Semelhante a Implementing High Performance Drupal Sites
Semelhante a Implementing High Performance Drupal Sites (20)
Último
Último (20)
Implementing High Performance Drupal Sites
- 1. Presentation Title w w w . u n i m i t y . c o m DEC 2010 Implementing High Performance Drupal Sites Unimity Solutions. 3, 5th Floor, "Kasi Arcade" 116, Thyagaraya Road, T.Nagar, Chennai 600017 India, Phone: (91- 44) 43923800 www.unimity.com By Kamalakanan & Shyamala
- 9. Event Based Caching vs Time Based Caching twice a day (Separate cron ) No Tag cloud All Once a Day (Separate cron) No Birthday Wishes Home Once a day (separate cron) No Active members Home yes Display Name--> Did You Know Home Home yes Display Name --> Spotlight Home Home yes Display Name --> Home Slide Home Home Time Based - update Frequency Event based Display Name View Name Page
- 10. Importance of planning for Cache Sheet yes Display Name --> Announcement news_page Announcements yes Display Name -->Buzz Zone yes Display Name --> Recent topics, No Display Name -->Popular in corporate zone, yes Display Name --> Corporate Zone, rightside_blocks yes Display Name --> News news_page News Time Based - update Frequency Event based Display Name View Name Content Type
- 13. Expert Knowledge Groups – Groups.Drupal.Org
Notas do Editor
- Performance of a website is the Speed at which the website can be accessed by the end user. - how fast the website can handle a single request. Scalability - how many requests your application can handle at the same time, or the amount of information it can store and process. - capability of a system to increase total throughput under an increased load when resources are added
- Three Layers of performance are Users(Browser), Server side and Application (i.e Drupal) We will be concentrating on Application. Here I will brief you on User end. Size of page components plays a major part in perfromance - HTML Dom elements - Js files - CSS files - images To reduce the size of the components - Write simple code with good planning. - Minfy the js and CSS files - compress page components using GZIP of Apache No of request ( less no of request faster the page load ) To reduce the request compress many files into single files for js and css ( if you have many css or js files ) use sprite images for CSS background image Browser Cache Assign Expires header for long period, so that browser woouln’t request the page components for every page request Enable ETags which assist to load the files that is changed.
- Drupal in Core has a dedicated page for configuring the cache and page compression In Settings page Drupal allow us to configure the cache by enabling and assigning the lifetime for the cache There a option to enable the block cache – which will be useful for authenticated users , as page cache won’t available for authenticated user, but one thing we have to keep in our mind is that block module won’t cache the block if the user access is defined. Enable the page compression Optimise the CSS files – which will compress many files to single file Optimise the Javascript file - which will compress many file to single file. Other than the Drupal core, the module we use frequently like views and panels will also provides us feature to manage the cache on there own. Views provide us two options to cache, i.e cache query and cache rendered html which is time based. For Logging Error’s Drupal provides two option one is Dblog and Syslog, Dblog is used to log the activities in DB, whereas Syslog user file system to log. In high traffic sites it is recommended to use syslog and DBlog frequent writing will cause the mysql to slow. And if your db engine is Myisam it will be more slow as Myisam has table lock. Use Developer tools, to assist in fine tuning the performance for example use Devel module to analyse the SQL query executed while a page renders. - Check the repetition of SQL queries, if so try to reduce the duplication, if the same function getting called more than once and executing same query then use static variable to return the result set. - Check the execution time of the SQL query if it takes more than 3 ms then analyse the query with Explain command in mysql, with the help of this analyses try to index the columns of the table used in “where” condition. Makesure all tables using index. Use DB tuner a module suggest to fine the MYSQL database - it will suggest to index the some CCK table columns - it will suggest some changes to MYSQL configuration ( Get the help of the system Admin to implement this. Don’t go by all suggest, take decision on your own by analyzing other parameters )
- Always it is recommended to follow the Coding standards defined in Drupal.org Split the module file as possible if the line of code goes more than 300 Get the clue from other drupal contributed module, it is familiar to see theme.inc, admin.inc, pages.inc in the module folder Resuse Drupal functions – before writing a function make sure, Drupal doesn’t have the same. Use Static Variables to cache the content inside a function, you can refer the node_load for example , node_load will store the node objects in the static variable and it will render the a node object singe time, next time it will return the object from the cache. This cache will be retained for single page render. Query VS use of views Views always use left Join which will have some impact on execution time. View is heavy compare to Query as we have freedom to construct the query as we required. views allow us to build a block or page with minimal efforts. So if we use views don’t think that all queries wrote by views are optimized, Analyse each query and make required changes to the views query using appropriate hook’s hook_views_query_alter(&$view, &$query) { If required you may also write your own cache using cache api CACHE_SET, CACHE_GET
- Advacned Caching systems are available instead of Drupal’s DB cache. Like, BOOST, MEMCache, Varnish. Boost is the module which saves all pages as static html files and serve static files to the anonymous user. MemCache is the module which uses the memcache to store the caches in the memory instead of DB Varnish is also a like memcache which caches the pages in memory.
- The Event Based Caching is one of powerfull way of handling our cache in drupal, We must have a through cache management, usually the cache is managed time based. But this time based cache is having downside that is if the time expires, though the content changed or not it will re-generate cache content, as this is as unneccesary load to server and So cache the content for long life term and clear cache only required region or block every event triggered. This will help us to reduce the load to server and serve the content more from cache.
- This is the template used to manage cache for time based.
- This is the template used to manage cache for event based.
- Less SQL Path round trips Maintains a list of white listed paths that need url Alias, eg user/ doesnot use path alias, then no query sent to path table Per page cache of Pathalias On Cache miss only a particular tables caches get rebuilt and on Cache hit with just a couple of queries the pages are built. The down side is the storage need per page & how this increases with no of pages in a site - memcache. entity load vs node load functions - array of entities at a time, the concept of multiple load Per CCK storage no longer there -> could be a load, write storage backends raw Drupal 7 is still bad then Drupal 6, but can easily plugin external caching systems & storage engines to improve perforamcne.
- Question ?