Posted by walkah on October 3, 2011 at 9:05pm
Start:
2011-11-12 (All day) - 2011-11-13 (All day) America/Toronto Organizers:
Event type:
Drupalcamp or Regional Summit
Save the date! DrupalCamp Toronto 2011 is coming!
We'll be running a two day event on November 12th and 13th at George Brown College in Toronto. Mark your calendars for a full weekend of Drupal awesome stuff.
For full details, registration and session proposals check out: http://2011.drupalcamptoronto.org/
When: November 12th & 13th, 2011
Where: George Brown College, 290 Adelaide Street East. ( map: http://g.co/maps/kk2yj )
Comments
Module/Core Suggestion
Hi Guys,
I wish I could have made it to the DrupalCamp in TO. I am so sad due to it.
I have had an idea for a module for quite some time and was wondering if something is already available.
Name: Module Prioritizer
Functions:
- based on a provided URL path you can disable certain modules to lighten the page load, even when page cache is on.
- examples: Ubercart is a very heavy module, it would be great to disable this module and its submodules on homepage page loads if none of the ubercart functions are called. it will speed up page load significantly in my opinion.
Please let me know if something like this could have a purpose.
Matt
That presumes that there's no
That presumes that there's no "cart" icon or the like on the homepage.
This concept did exist years ago in a Core module called Throttle. It was eventually removed because the performance gains were negligible but the hair-pulling (why is this only broken sometimes?) was high.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
No benefit?
The idea sounds good, but for most cases, it's less helpful that you might think. The weight of "Loading" a module is negligible assuming you've got APC or other op-code cache. The contribution of a module to the code actually executing on a specific page (and the corresponding msyql calls) is going to depend on the page and what the module might be trying to do. A badly written module, or one that is doing things that you don't need it to do, are more likely culprits.
If you really want to optimize your front page, first get rid of all the modules you don't actually need, and turn off the features of the remaining ones that you don't need. Then you can start profiling to find out what might be slowing it down.
And of course if you're trying to make your front page really snappy for first time anonymous visitors, nothing's going to beat Varnish or equivalent front-end proxy that avoids Drupal altogether.