Acest site este o încercare de a spori comunicarea dintre cei mai activi dezvoltatori pe CMS Drupal - bloggeri. Dacă sunteți blogging despre Drupal, atunci sunteți gata să vă împărtășiți cunoștințele, ajutați-i pe alții. Nu întotdeauna cunoștințele tale ajung la consumator. Sarcina acestui site este să agregați cunoștințele diferitelor bloguri într-o singură bandă și să aduceți utilizatori activi pe blogurile dvs.
Activitatea utilizatorilor de pe site-ul dvs. va fi un stimulent suplimentar pentru munca viitoare.
Mult noroc în toate eforturile voastre!
Pe unul dintre proiecte, m-am confruntat cu nevoia de a optimiza site-ul. După ce am analizat partea de server a site-ului, am observat că bootstrap-ul pentru fiecare încărcare de pagină a fost consumat
350 de milisecunde. Destul de mult, având în vedere că numai încărcarea componentelor necesare. După ce am petrecut mai mult timp în căutarea problemei, am aflat că de fiecare dată când am încărcat pagina, Drupal mi-a scanat din nou toate dosarele cu teme și module. Aceasta a fost baza pentru întârzierea în bootstrap. Această scanare a fost cheltuită în jur de 280 milisecunde (102 module și 2 teme). Și acest lucru, în ciuda faptului că proiectul este pe un server separat, care este complet ascuțit pentru Drupal 7.
După ce am realizat problema, am avut două întrebări destul de logice:
1. Ce @ # $ atât de mult timp?
2. De ce a fost imposibil să-l cache?
După cum sa dovedit - Drupal este deja caching. Și totul funcționează de obicei bine și corect. Dezvoltatorul nu începe să șterge modulele incorect. Unii dezvoltatori elimină modulele într-un mod din lemn: prin eliminarea fizică a modulului de pe server. Se pare că modulul nu mai funcționează și rezultatul pare a fi realizat. Dar ce se întâmplă în Drupal?
Material original original:
Toate articolele din blogger: Drupalace
Trimiteți-le prietenilor: