Mi., 12/09/2012 - 15:32
Generell alles auf http://2bits.comSuper infos. http://2bits.com/articles/high-php-execution-times-drupal-and-tuning-apc-includeonce-performance.html http://www.vmirgorod.name/10/11/5/tuning-drupal-performance http://buytaert.net/drupal-webserver-configurations-compared < TEST BY DRIES http://www.morningtime.com/Drupal-6x-Performance-Guide/513 http://wimleers.com/article/improving-drupals-page-loading-performance http://2bits.com/articles/php-op-code-caches-accelerators-a-must-for-a-large-site.html http://www.metaltoad.com/blog/faster-404s-drupal-and-imagecache http://drupalperformanceblog.com/ http://www.drupalcenter.de/node/24434 http://blogs.middlebury.edu/lis/2010/05/17/website-performance-pressflow-varnish-oh-my/
Amount of Modules, performance?http://2bits.com/articles/server-indigestion-the-drupal-contributed-modules-open-buffet-binge-syndrome.html http://2bits.com/articles/measuring-memory-consumption-by-drupal-bootstrap-and-modules.html http://2bits.com/contents/articles | THE DRUPAL PERFOMANCE BLOG !!!!! http://2bits.com/articles/php-op-code-caches-accelerators-a-must-for-a-large-site.html
DRUPAL GROUPShttp://groups.drupal.org/node/95599 http://groups.drupal.org/node/10835 http://groups.drupal.org/node/27174 http://blamcast.net/articles/speed-up-drupal http://groups.drupal.org/node/50383 http://drupal.org/node/326504
- * I'd strongly suggest refactoring how you do the user uploads (possibly using CCK filefield and CCK field permissions instead of the core upload) and get away from private downloads. As long as you have it set to private, you're going to have no end to the performance problems.
- * 130 modules? Egads! Surely you can combine and/or reduce some of those - especially the 50 custom - modules. That is a phenomenal amount of work to be do on every single bootstrap.
- * 4G of RAM might not be enough with that many modules and a reverse proxy cache like Squid. How large is your APC cache and is it full? Same for Squid - how large is it and is it full? What's your Squid cache hitrate?
- * Pressflow - learn it, use it. It may help significantly, especially in bypassing the bootstrap for anon users. It's perfectly safe - I've switched live sites to/from Pressflow with no issues at all.
- * Varnish - you already have Squid set up, so this might not be as useful. That said, I am a die-hard supporter of the Pressflow-Varnish stack. It does wonders for performance. It might be worth looking at replacing Squid with Varnish, but it likely won't fix the majority of your problems. You'll likely see an improvement in performance over Squid, but we're talking differences in the tens or hundreds of milliseconds, not the tens of seconds you're seeing here.
- * Cookies - eradicate them for anon user sessions. For the most part, cookie = no cache. There are very few valid reasons for a cooking to be set on an anon user's session. Look at your modules and root out the ones that set cookies on anon users - especially ones that don't clear the cookies. Once a cookie is set on a session, you're probably getting little or no caching on that session even if the content itself is eminently cache-able. Commonly-used modules that do this include Masquerade and Hierarchical Select, but I am sure there are quite a few others.
- * Memcache - if you're not using it, start. If you are, check your config. I've had better luck with using the Memcache API directly instead of Cacherouter on high traffic sites. When configured to use APC, Cacherouter seems to have cache fragmentation problems in my experience.
- * CSS sprites for theme images - it's a bit of work, but it'll reduce the excessive number of HTTP requests.
- * DON'T HACK CORE. I see you tried. Stop before you slide down that slippery slope into madness. You'll only regret it.