Generell alles auf http://2bits.com
http://buytaert.net/drupal-webserver-configurations-compared < TEST BY DRIES
Amount of Modules, performance?
http://2bits.com/contents/articles | THE DRUPAL PERFOMANCE BLOG !!!!!
* 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.
http://2bits.com/drupal-planet/reducing-server-resource-utilization-busy-sites-implementing-fast-404s-drupal.html | 440 optimize
http://groups.drupal.org/node/15663 | High volume Drupal sites - what do we need to know?
Modules for monitoring and troubleshooting
uses apache mod_sendfile to modify the headers and decrease server load.
http://drupal.org/handbook/modules/throttle | IM CORE ENTHALTEN
http://drupal.org/project/boost | superschnelle seiten, legt files ab
http://drupal.org/project/simple_cache | ähnlich wie bosst, funktioniert für anonymous wie angemeldete benutzer. legt code in db ab
http://drupal.org/sandbox/Caseledde/1970904 | genial, cached den viewmode. superspeed
Cache pre Erzeugen
Theroy of load balancing
Verteilung der last auf verschiedene Server:
Drupal Gastro Speicherverbrauch-fuxxz.pdf
Drupal Performance and Scaling Part 1 - Anonymous Users _ chadcf.pdf