Make Drupal faster BoF results
On Wednesday's BOF session, we talked about the direction we'd like to see Drupal take to improve performance - here are the notes from that session.
- Custom blocks (from the core block module)
Custom blocks are declared as DRUPAL_NO_CACHE (7) / BLOCK_NO_CACHE (6), with the comment "Not worth cacheing". This comment is predicated on a cache-request being a DB request, and so a request for the block-data is as expensive as a request for the cache data. However, running cache through memcache means that a cache request is much more performant than a DB request, so there is benefit.
Conclusion: Change block-module to use DRUPAL_CACHE_GLOBAL
Need to work out how this can work with PHP input filter - Drupal.org doesn't offer any advice or recommendations on performance best-practice (e.g. use memcache, integrate with Varnish, run page-cache, etc).
Conclusion: Write a Performance section for Drupal.org to set expectations on core performance, and advice on tools and approaches to make this even better. - Full page cache is a significant performance win, and works out-of-the-box, even on shared hosting. If, for example a dependency on memcache were introduced, this would be a massive performance hit for a large number of users.
Conclusion: Full-page cache should continue to work in core, without any additional applications. - Memcache is one of the first recommendations anyone makes for improving Drupal performance, and is widely accepted.
Conclusion: Bring memcache into core. - The memcache module has a number of critical bugs, and if it's to go into core, it must be stable and well-tested.
Conclusion: Review the tests for memcache, and improve them where needed - The admin-reports page could be used to report perceived 'performance errors' and make recommendations on addressing these. However, if the recomendations were based on using contrib modules, these are usually faster-moving than core, and patching core to add new recommendations introduces additional risk and delays.
Conclusion: The admin-reports page isn't to be used to report on performance issues (except in exceptional cases where a package is part of core and a warning is warranted) - There's a performance overhead of template preprocess, and it becomes more difficult to cache data as it goes through the theme layer.
Conclusion: Investigate the context-broker system, with the goal of bring local context to a template level and removing template preprocess.
Comments, discussion, and patches on the above are welcome :-)
These notes are from the BOF session led by ChX at Drupalcon Copenhagen 2010.
Groups:
Login or register to post comments
What's a context-broker
What's a context-broker system ? Theme preprocessing shouldn't be a performance issue, or otherwise, we wouldn't have added preprocessing for theme functions, too...?
Daniel F. Kudwien
unleashed mind
Context broker
http://groups.drupal.org/butler -- they want a lot more that I don't necessarily but the centralized context system is nice. In short, preprocess spends a lot of time producing variables you don't necessarily need. Instead, we should try something like instead of writing
<?phpprint $foo;
?>
<?phpd('foo');
?>
Memcache is one of the first
If that does become a reality, I would also suggest adding APC caching into core, since APC is probably even more recommended than memcached and there's even a few shared hosts out there that offer APC, albeit with a rather small user cache size.
There was another posting in the group we talked about this (mikeytown started it). What I believe would be awesome is a Drupal core cache class that engines could extend. Core would ship with db, memcache and APC. There would also be a mechanism to add new drop-in caching engines by including them in settings.php. That way the XCache an EAccelerator people can also benefit if someone wants to write the abstract class engine for them. Then we would keep core down to maintaining the 3 biggest caching engines (APC, Memcache and DB) and other engines would be handled by contrib.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
?
You probably mean this http://drupalcode.org/viewvc/drupal/drupal/includes/cache.inc?view=markup
Daniel F. Kudwien
unleashed mind
As a side note, the main
As a side note, the main obstacle to implementing path-alias caching is and seemingly has always been that memcache is not an assumed part of core, so if this recommendation is implemented, it would also be possible to move that into core.
Or is that a moot point in D7?
Yup that's what I mean LOL. I
Yup that's what I mean LOL. I say expand on that and include support for the current DB and add memcache and APC. That would benefit the greatest number of uses and I think usage of other caching engines is small enough to justify keeping those in a contrib state.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
It seems to me that one of
It seems to me that one of the cornerstones of a performance improvement strategy would first be to empower the user community with the tools they need to identify performance bottlenecks in the first place. We have tools, such as devel, that allow us to specifically analyze query performance, and more generally analyze page performance. Beyond this, the question 'Why does my page take X ms to load?" is a bit of a black hole for most.
I recently read this post by Brian Mercer regarding the availability of a XHProf contrib module for drupal, and went to work getting it setup on my system. It was, quite honestly, a 'whole new world' with respect to understanding what was eating through cpu cycles and memory. I immediately (to my surprise) found that Nice Menus was a terrible resource hog (it caches nothing), and that path_auto is responsible for the vast majority of my page load times during node creation.
PHP profiling tools have existed for some time, but making them convenient to use for the drupal community has - so far - been something of a pipe dream.
Is memcache even the right
Is memcache even the right technology? It's not clear to me that in 2 years there won't be a much better option.
Well memcache has already
Well memcache has already been out 7 years and is widely used and accepted as the defacto caching engine. It's also got support from big sites like Facebook.
Will another caching engine be out in 2 years? I'm sure it will, but it won't have the penetration that Memcache does then. You still have to wait on things like interfaces to PHP and packages to be put out for the major OS' out there. That won't happen in 2 years, so I would say memcache will be the biggie for at least 5 years, but probably more like 10+.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.