Performance - Scalability

Mi., 12/09/2012 - 15:32

Generell alles auf

Super infos. < TEST BY DRIES

Amount of Modules, performance? | THE DRUPAL PERFOMANCE BLOG !!!!!




  1. * 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.
  2. * 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.
  3. * 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?
  4. * 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.
  5. * 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.
  6. * 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.
  7. * 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.
  8. * CSS sprites for theme images - it's a bit of work, but it'll reduce the excessive number of HTTP requests.
  9. * DON'T HACK CORE. I see you tried. Stop before you slide down that slippery slope into madness. You'll only regret it.

Overview | 440 optimize | High volume Drupal sites - what do we need to know?

General Infos

Database tuning

Modules for monitoring and troubleshooting

Performance Modules uses apache mod_sendfile to modify the headers and decrease server load.

Drupal Module

COLLECTION: | IM CORE ENTHALTEN | superschnelle seiten, legt files ab | ähnlich wie bosst, funktioniert für anonymous wie angemeldete benutzer. legt code in db ab | genial, cached den viewmode. superspeed

Cache pre Erzeugen



Theroy of load balancing

Verteilung der last auf verschiedene Server: Image removed.Image removed.

pfds,%20CacheRouter%20and%20Memcache%20API_0.pdf Namen drupal-single-server-3.4-million-page-views-a-day.pdf Drupal Gastro Speicherverbrauch-fuxxz.pdf Drupal Performance and Scaling Part 1 - Anonymous Users _ chadcf.pdf
Add new comment
The content of this field is kept private and will not be shown publicly.

Plain text

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <drupal-entity data-*>
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.