Posted by ManyNancy on January 18, 2010 at 7:17am
I just installed Mercury, and I see these 3 pressflow modules. Should I enable them? Why are they not enabled by default?
I decided that my pressflow folder should also be in ebs, so I moved them to a different folder. I only changed etc/apache2/sites-available/default to point to the new location, is there anywhere else I should change?
Mercury uses external caching by default, but drupal says: The following enabled modules are potentially incompatible with aggressive- and external-mode caching and will not function properly: css_gzip, devel, notifications, og, persistent_login, statistics, subpath_alias, troll, update_form_enhancement, url_alter.
Should I still use external caching?
Thanks.
Comments
Does anyone know? Thanks.
Does anyone know?
Thanks.
re: Does anyone know? Thanks.
You would also want to change the cronjob that runs drupal cron (since is runs drupal cron via drush).
Hope this helps,
Greg
--
Greg Coit
Systems Administrator
http://www.chapterthree.com
External Caching
External Caching mode needs to be on if you want Varnish to handle anonymous page requests.
The conflict warnings are alerting you to the fact that some of your modules implement hook_boot and/or hook_exit, which are not called when external or aggressive page caching is used. In the case of Varnish, anonymous page requests will never even hit the Drupal backend (which is a feature), but this does mean, for instance, that the statistics.module won't be able to count those pageviews. I'm not familiar with all the modules listed, or what they do for your site, but you should probably review the impacts as part of your move to Mercury.
Baiscally, in order to take advantage of the 200x performance gains that are possible with this kind of next-generation caching system, you need to accept the fact that Drupal will not know about every single pageview. Depending on your use-case that may or may not be acceptable. Your mileage may vary. ;)
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
Thanks for answering. The
Thanks for answering. The boost module has a Stats block which handles the issue of views counting. (Think it bootstraps drupal with ajax) Is there something similar for Mercury?
Any Ideas on patching organic groups (og) to use external cachin
It would be most helpful if someone can post a quick guide / patch so that og (organic groups) works with external caching on pressflow. Will be willing to contribute
does OG not work with
does OG not work with varnish/pressflow?
Follow me on twitter: @drupalninja
og works with mercury
@jaykali og does work with pressflow according to my tests. Nice twitter handle btw
OG Module on Pressflow
OG works fine. But the issue is, to quote Josh "....some of your modules implement hook_boot and/or hook_exit, which are not called when external or aggressive page caching is used" [#comment-122364]. OG is one of those modules.
OG and How to Improve Performance?
One of my newest sites will be almost entirely registered users in an OG educational environment. In the past, Pressflow with Boost has been enough of my largely anonymous viewer sites. Will these work with OG? And, in general, what should I do to improve performance with OG?
OG + Pantheon = no problems
I use Pantheon with Eduglu (which is a OG-based distro) on my sites and it works just fine. A lot of the caching techniques work only with anonymous users but you'll still see a nice boost from using Pantheon. See also JoshK's writeup here about scaling Open Atrium - http://groups.drupal.org/node/56428
Kyle Mathews
OG + PAnels +
OG + PAnels + roles/notifications is giving me serious 503 problems durring registration
www.thecenterofthenet.com
http://cn.linkedin.com/in/roberpteatonjr
http://www.facebook.com/robertp.eaton
http://www.alamy.com/stock-photography/6A42F1A1-E40A-48FD-8C7F-FF258A401...
Hi Antinsa; 503s usually mean
Hi Antinsa;
503s usually mean there was a php error on the Drupal site. Check your error logs to see what it was.
It's important to note that while Varnish + Pressflow + External Cache setting will essentially always serve pages to anonymous users right out of cache, the first time an anonymous user visits a page Drupal will load it. This is actually true for different anonymous users with different encoding types HTTP 1.0 vs 1.1, etc...
This means that some anonymous traffic does hit the Drupal site which is why it matters if all the modules you run are compatible with External caching and don't rely on hook_boot or hook_exit.
BUT! However!
If you know that any things done by those modules aren't needed by anonymous users because any actions the modules need to take will be/have been taken by authenticated users on your site (like the admin) already, then you're OK to use them with External
The poster probably has their per module questions answered by now, but in case someone searches and finds this thread:
css_gzip: Since your CSS files are recreated after clearing cache by an admin, you're OK because hook_boot and hook_exit are called for the admin's session and the css_gzip files are remade and stored in the files folder.
devel: you should never be showing devel joy to anon users so it won't matter (of course you should never have it on production sites either)
notifications: if this is just for logged in users you are OK
og: If you are only allowing logged in users to post to og, you are OK (though OG is big so there may be some small hiccups somewhere)
persistent_login: this actually will have issues with Varnish. Your mileage may vary. Worst case scenario is that it just doesn't work and folks have to log in when they come back.
statistics: You won't get Drupal stats for anonymous visits. Use something like Google Analytics since it is done client-side via JS. Why pay to have your Drupal site crunch stats when Google will do it for you for free?!
subpath_alias: Not sure about this one. In theory if an admin/logged in user visits them after they are made then you should be OK.
troll: I imagine this one will be OK. Make sure you have your reverse proxy settings in place in your settings.php as I imagine this puppy does IP checking
update_form_enhancement: no idea;
url_alter: should be the same as subpath_alias