Lehet, hogy szakmiatlan a kérdésem, de mikor kezd csökkeni jelentősen a Drupal sebessége. Van jelentős különbség ha 10, 100, vagy 1000 node van egy weblapon?
bár szerintem egyszerű választ nem lehet rá adni. Persze nem csak a node-ok száma, hanem egész más is lehet a szűk keresztmetszet. Van valakinek tapasztalata?
Tapasztalataim szerint teljesen mindegy, hogy tíz, vagy tízezer node, vagy felhasználó található a rendszerben. Az ilyesmi dolog amúgy sem a Drupaltól függ (az csak egy alkalmazás), hanem a webszervertől, adatbáziskezelőtől, PHP -től. Ha ezek normálisan be vannak állítva, és a gép is megfelelő paraméterekkel rendelkezik (pl. elfér az adatbázis a memóriában), akkor szerintem nincs érzékelhető teljesítménycsökkenés.
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:
Fibonacci számsorozat egy olyan tipikusan jó példa, melyen ezt be lehet mutatni. A definíció szerinti rekurzív megvalósításról van itt szó. Főleg akkor szoktam elővenni, amikor valaki azt írja a gép teljesítménye a szűk keresztmetszet.
A Fibonacci O(n), ha sorozat utolsó két elemét letárolod, vagy nem? Régen játszottam én ilyesmivel :) A legtöbb algoritmusra van legfeljebb O(n^2) gyorsaságú megoldás, szerintem kevés ilyen vagy ennél lassabb algoritmus van Drupalban (ha van egyáltalán).
Én konkrétan a következő részre reagáltam:
Tapasztalataim szerint teljesen mindegy, hogy tíz, vagy tízezer node, vagy felhasználó található a rendszerben. Az ilyesmi dolog amúgy sem a Drupaltól függ (az csak egy alkalmazás), hanem a webszervertől, adatbáziskezelőtől, PHP -től.
Ez ilyen formában nem igaz, mert függ a node-ok és a felhasználók számától a válaszidő. Pont ez a jó a Drupal-ban, hogy meg lehet nézni, hogy mitől függ:
Itt a kódból látszik, hogy függ a node-ok számától, a felhasználók számától és a verziók számától is (mely minimum a node-ok száma) Ez az indexelés miatt log(n)-es, ami jó, de nem mondanám azt, hogy nem függ tőle, de igaz, hogy elhanyagolható, hisz 1000 node-nál ez a lépésszám ~10, 10^12-nél ~40.
De jön a DE, ami itt nagyon is DE mert bármelyik modul kapcsolhat adatokat a node-hoz, és már egy apró figyelmetlenségnél (nincs index) is borul a fenti összefüggés és lineáris lesz a keresés hossza. (n/2) Ügyesebb kismókusok meg írhatnak olyan modult ami aztán ezt fellövi az égbe. Lásd olyat akarok mint az iwiw, vagy egy dögös mlm rendszer.
Ha megnézed, hogy hogy tárolja a Drupal a kategóriákat, akkor láthatod, hogy egy kövér megfelelően mély hierarchiával rendelkező kategória rendszer is csodákat tud ám tenni. http://api.drupal.org/api/function/taxonomy_get_tree/5
Hierarchikus adatokat sokkal hatékonyabban is lehet tárolni, ami nem azt jelenti, hogy a Drupal-é használhatatlan, de több százezer kategóriát tartalmazó 50-60 mélységgel rendelkező rendszerre nem alkalmas. (itt most nem node-okról van szó, hanem kategóriákról.)
Talán az elfogadható, hogy egy általános célú rendszer ne teljesítsen maximálisan minden speciális esetben ;)
Szóval igen is függ a Drupal-tól és a tárolt adatok mennyiségétől az, hogy milyen gyors a rendszered. Egyértelmű választ pedig nem lehet adni az indító kérdésre, hisz nem tudjuk, hogy milyen és mennyi egyéb modult használ a kérdező.
Ez engem is érdekelne,
bár szerintem egyszerű választ nem lehet rá adni. Persze nem csak a node-ok száma, hanem egész más is lehet a szűk keresztmetszet. Van valakinek tapasztalata?
Nagy Gusztáv
mondjuk soha?
Tapasztalataim szerint teljesen mindegy, hogy tíz, vagy tízezer node, vagy felhasználó található a rendszerben. Az ilyesmi dolog amúgy sem a Drupaltól függ (az csak egy alkalmazás), hanem a webszervertől, adatbáziskezelőtől, PHP -től. Ha ezek normálisan be vannak állítva, és a gép is megfelelő paraméterekkel rendelkezik (pl. elfér az adatbázis a memóriában), akkor szerintem nincs érzékelhető teljesítménycsökkenés.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Ez nem ilyen egyszerű
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
Palócz István
https://palocz.hu | https://tanarurkerem.hu
Melyik az O(2^n)
Melyik az O(2^n) függvény?
Aries
http://aries.mindworks.hu
állatorvosi ló
Fibonacci számsorozat egy olyan tipikusan jó példa, melyen ezt be lehet mutatni. A definíció szerinti rekurzív megvalósításról van itt szó. Főleg akkor szoktam elővenni, amikor valaki azt írja a gép teljesítménye a szűk keresztmetszet.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
Konkrétan Drupal-ra
Konkrétan Drupal-ra gondoltam :)
A Fibonacci O(n), ha sorozat utolsó két elemét letárolod, vagy nem? Régen játszottam én ilyesmivel :) A legtöbb algoritmusra van legfeljebb O(n^2) gyorsaságú megoldás, szerintem kevés ilyen vagy ennél lassabb algoritmus van Drupalban (ha van egyáltalán).
Aries
http://aries.mindworks.hu
Nincs konkrét példám
Én konkrétan a következő részre reagáltam:
Tapasztalataim szerint teljesen mindegy, hogy tíz, vagy tízezer node, vagy felhasználó található a rendszerben. Az ilyesmi dolog amúgy sem a Drupaltól függ (az csak egy alkalmazás), hanem a webszervertől, adatbáziskezelőtől, PHP -től.
Ez ilyen formában nem igaz, mert függ a node-ok és a felhasználók számától a válaszidő. Pont ez a jó a Drupal-ban, hogy meg lehet nézni, hogy mitől függ:
http://api.drupal.org/api/function/node_load/5
Itt a kódból látszik, hogy függ a node-ok számától, a felhasználók számától és a verziók számától is (mely minimum a node-ok száma) Ez az indexelés miatt log(n)-es, ami jó, de nem mondanám azt, hogy nem függ tőle, de igaz, hogy elhanyagolható, hisz 1000 node-nál ez a lépésszám ~10, 10^12-nél ~40.
De jön a DE, ami itt nagyon is DE mert bármelyik modul kapcsolhat adatokat a node-hoz, és már egy apró figyelmetlenségnél (nincs index) is borul a fenti összefüggés és lineáris lesz a keresés hossza. (n/2) Ügyesebb kismókusok meg írhatnak olyan modult ami aztán ezt fellövi az égbe. Lásd olyat akarok mint az iwiw, vagy egy dögös mlm rendszer.
Ha megnézed, hogy hogy tárolja a Drupal a kategóriákat, akkor láthatod, hogy egy kövér megfelelően mély hierarchiával rendelkező kategória rendszer is csodákat tud ám tenni.
http://api.drupal.org/api/function/taxonomy_get_tree/5
Hierarchikus adatokat sokkal hatékonyabban is lehet tárolni, ami nem azt jelenti, hogy a Drupal-é használhatatlan, de több százezer kategóriát tartalmazó 50-60 mélységgel rendelkező rendszerre nem alkalmas. (itt most nem node-okról van szó, hanem kategóriákról.)
Talán az elfogadható, hogy egy általános célú rendszer ne teljesítsen maximálisan minden speciális esetben ;)
Szóval igen is függ a Drupal-tól és a tárolt adatok mennyiségétől az, hogy milyen gyors a rendszered. Egyértelmű választ pedig nem lehet adni az indító kérdésre, hisz nem tudjuk, hogy milyen és mennyi egyéb modult használ a kérdező.
pp
(a válasz meg mindig ott a kódban ;))
Palócz István
https://palocz.hu | https://tanarurkerem.hu
gyorstár
Ha a tárhelyszolgáltatód egy olcsójános (gyenge hardver, vagy színvonalas hardver de túlterhelve).
CCK és Views használata esetén átgondolatlan tartalomszervezés, emiatt egy egyszerű kis listázáshoz is be kell hívni a fél adatbázist.
Ha nincs bekapcsolva a gyorstárazás.