Archief - Drupal 7, Varnish, MailChimp en block caching = disaster?

Ff een long shot, en om niet heel mijn epistel opnieuw neer te tikken, dit heb ik net op het (niet heel actieve) Drupal.be forum gezet ook : Drupal 7, Varnish, MailChimp, block caching & vreemde issues | Nederlandstalige Drupalgemeenschap

De TL;DR versie hier :
Een D7 site die draait achter Varnish 3, en de Varnish module (https://drupal.org/project/varnish) is correct geactiveerd. Varnish caching werkt naar behoren (getest met curl -I). Als ik block caching - in de prestaties settings - aanzet gebeurt er iets vrij vreemds. Een block om in te schrijven op een MailChimp mailing list (standard block van https://drupal.org/project/mailchimp) wordt dan blijkbaar nog eens apart gecached, waardoor die naar random pagina's gaat posten (ipv de huidige). Zet ik block caching af, dan lijkt dit zich niet voor te doen. Het gaat over unauthenticated views overigens...

Is dit normaal gedrag voor Drupal 7? Even verduidelijken : ik dacht dat block caching ook rekening hield met de pagina waarop het blok staat (toch zeker als het over formulieren gaat lijkt mij dat een vereiste). Schijnbaar is dat dus niet zo...

Persoonlijk kan ik niet helpen, maar mss dat men uw hier verder kan helpen:
https://groups.drupal.org/high-performance
Drupal - Open Source Content Platform

Eventueel op één van de drupal IRC channels eens gaan raad vragen?

Voorlopig heb ik de block caching gewoon afgezet (uiteindelijk vangt Varnish de load toch perfect op, en eens iets langer doen over 1 page load kan er wel door ). Ik vond het gewoon wat vreemd. MailChimp is de grootste bottleneck eigenlijk... Vertraagt de boel wel enorm bij momenten (pieken tot 1 min. ! volgens NewRelic) terwijl het gewoon een "registreer mijn email adres op uw mailing lijst" formulierke is.

*edit* Toch eens de MailChimp module nagekeken, en blijkbaar zou die dat blok gewoon per gebruiker cachen (DRUPAL_CACHE_PER_USER), dat kan wel al veel verklaren (aangezien het probleem zich bij anonymous views voordoet...) - daar zou DRUPAL_CACHE_PER_PAGE wel mogen bijstaan denk ik (-> http://drupalcode.org/project/mailc...s/mailchimp_lists/mailchimp_lists.module#l841). Dat ik er niet eerder aan dacht van dat eens te controleren... Last van de hitte (en wat te veel stress gehad) .

dJeez zei:

Voorlopig heb ik de block caching gewoon afgezet (uiteindelijk vangt Varnish de load toch perfect op, en eens iets langer doen over 1 page load kan er wel door ). Ik vond het gewoon wat vreemd. MailChimp is de grootste bottleneck eigenlijk... Vertraagt de boel wel enorm bij momenten (pieken tot 1 min. ! volgens NewRelic) terwijl het gewoon een "registreer mijn email adres op uw mailing lijst" formulierke is.

*edit* Toch eens de MailChimp module nagekeken, en blijkbaar zou die dat blok gewoon per gebruiker cachen (DRUPAL_CACHE_PER_USER), dat kan wel al veel verklaren (aangezien het probleem zich bij anonymous views voordoet...) - daar zou DRUPAL_CACHE_PER_PAGE wel mogen bijstaan denk ik (-> drupalcode.org Git - project/mailchimp.git/blob - modules/mailchimp_lists/mailchimp_lists.module). Dat ik er niet eerder aan dacht van dat eens te controleren... Last van de hitte (en wat te veel stress gehad) .

Klik om te vergroten...

Goed dat ge de oplossing gevonden hebt... mss een issue indienen bij de module zodat andere het ook kunnen oplossen?

demon326 zei:

Goed dat ge de oplossing gevonden hebt... mss een issue indienen bij de module zodat andere het ook kunnen oplossen?

Klik om te vergroten...

Uiteraard volgt een PR (nu ja, patch in het geval van Drupal, ze zouden heel hun dev beter naar GitHub overzetten imho) als dat het oplost (nog niet de kans gehad om het te testen, maar in principe zou dat de issue toch moeten oplossen). Ik heb nog al patches ingediend (voor SOLR, ook een i18n issue).

Voor search_api_page ga ik in een dood moment ook eens kijken hoe die best i18n compatibel gemaakt kan worden (ipv dat via de search_api hooks te forceren), en dan volgt daar ook wel een patch voor.