AJAX vagyis AJAJ a Drupalban | Palócz István
dependantDropdown | drupal.org

Active Select | drupal.org

Egyre többször tapasztalom sajnos, hogy ez a "frissítés előtt mentsd le a fájlrendszert és az adatbázist" dolgot elég nehézkes megvalósítani. Nem tudom, kinek milyenek a technikai lehetőségei otthon/munkahelyén, de én itt egy elég "keskeny széles sávú" internetelérést használok. Ha frissítés előtt ftp -vel letöltöm a szolgáltatótól a fájlokat (mivel nincs mód a tömörítésre, ezért egyenként a sok kicsi fájl töltése amúgy sem leányálom), majd lementem a phpmyadmin -ból az adatbázist, az legalább húsz perc. Nos, ha ezek után valami gond van a frissítés során, akkor törlés után vissza kell tölteni mindent, ami a kimenő adatfolyam szűkösebb sávszélessége miatt nem áll meg háromnegyed óra alatt, de inkább több. És abbe még bele sem gondoltam, hogy mi van, ha a frissítéskor jelentkező probléma összetettebb (mondjuk valamelyik külső modul miatt), és ezért többször is szükséges az eredeti állapot visszatöltése a szerverre.
Vagy csak én látom úgy, hogy ez macera?

Nehéz kérdés, mert a teljesítmény függ a telepített moduloktól, valamint attól is, hogy az ember be van jelentkezve, vagy sem.

A kérdés az, hogy van-e olyan modul, ami extrém módon terheli a rendszert. Egy rosszul megírt algoritmus ilyenkor "csodákat művelhet". Tudok mondani 3 algoritmust, ami ugyan azt csinálja de a futási idő n függvényében a következő képen alakul: 2^n, C*n, C

Ez 10 elemnél rendre: 1024, C*10, C
1000 elemnél rendre: beláthatatlanul nagy szám nagyságrendileg 10^100, C*1000, C
A C egy tetszőleges pozitív 1-nél nagyobb szám. Amint látható az első megoldás már viszonylag kis elemszámnál is kvázi végtelen futásidőt jelent, míg a második és a harmadik nem.

Az ilyen hibás algoritmusokat igyekeznek elkerülni a Drupal-ban, de ez nem jelent garanciát arra, hogy minden modulban ugyan ezt teszik.

A node-ok és a tábla sorok számától meg egyértelműen függ az, hogy mennyi idő alatt kapod meg az eredményt, ezért is bontották szét a cache táblát több táblára, hisz régen csak egy tábla volt és ez eléggé terhelte a rendszert. Az se véletlen, hogy az adatbázis oszlopokra indexeket és elsődleges kulcsokat illik definiálni. (az előző példához hasonló eredmények miatt.)

Lebegjen szemünk előtt mindig a Légrádi féle felismerés:

Bármilyen gyors gépre lehet lassú programot írni

pp