Sziasztok,
Jeleztem a szerveresünknek hogy a site lassú, mire ezt a válazst kaptam tőle:
"1) a drupal6 DB alapú cacheit lődd ki, mert azok lassítják meg penetráns módon az oldalt a béna keresésekkel (szerk.: nagyon) nagy táblákon, helyette legyen file alapú. (kategóriákkal gyorsabb)
2) A szerveren emellett van memcached, ami meg jelentősen gyorsítja az oldalt. azt meg kapcsold be pls."
Bevallom nem tudom mit említ, így fordulok hozzátok, hátha tudtok segíteni ebben..
Előre is köszi
szerk.: átírtam a csúnya szót - aboros
Drupal verzió:
Fórum:
egyuttmukodo rendszergazda
mindannyiunk alma. :)
1. tegyel fel boost modult, fileba "cachel".
2. tedd fel a memcache modult. konfiguraljad be, done ;)
minden tabla legyen innoDB.
query cache (mysql konfig) ha lehet legyen nagy.
kapcsold ki a db zabalo modulokat, statistics pl tipikusan ilyen. slow query log segit.
tegyel indexeket az adatbazisban a megfelelo mezokre, segit a dbtuner modul.
-
clear: both;
Köszönöm Szépen!!!
Köszönöm Szépen!!!
Drupal full-stack developer at Wunderman Thompson Budapest
Azért az kérdés, hogy miért
Azért az kérdés, hogy miért is olyan (szerk: nagyon) nagyok azok a táblák. Ha azért mert sok bejelentkezett felhasználód van akik használják a rendszert, mert mondjuk egy közösségi oldalt csináltál, akkor a boost modul nem biztos, hogy sokat tud majd segíteni. Az ugyanis alapvetően a névtelen felhasználóknak szolgálja ki az oldalakat statikusan, fájl alapon. A bejelentkezett felhasználók továbbra is az adatbázisból kapják az oldalakat.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
nem, ritkán látogatott, napi
nem, ritkán látogatott, napi 80-100 UV-el, a cron napi 1x fut le.
Drupal full-stack developer at Wunderman Thompson Budapest
meg hát a cron fut szépen?
az elvileg ürítgeti a cacheket, nemigen lehet olyan, hogy nagyon nagyra nő a cache tábla. nézegettem most direkt a cache_* táblákat, közel se a legnagyobb táblák a dbben. érdemes lenne kideríteni mitől nő nagyon nagyra és pontosan melyik cache tábla.
-
clear: both;
kevés az információ
Ez pl. korántsem ilyen egyértelmű.
jolvan akkor pontositok
egy eleg nagy rendszerben nagyon sokat gyorsitott, hogy minden tabla innoDB. (eleinte probaltuk iras/olvasasi aranyok alapjan levalogatni melyik milyen legyen, ezutan kiprobaltuk mivan ha mind az. amugy ez a rendszergazda kulon kerese volt, nemtom milyen vudukat csinal a hatterben az indexelesekkel meg egyebekkel)
egyebkent meg ennyi infobol ennyi tanacsot tudtam adni, bocs, hogy felrevezettem...
-
clear: both;
Drupal eseteben egyertelmu
A hitetleneknek:
http://www.dynamiteheads.com/blog/jakub-suchy/migrating-your-site-pressf...
Nekem azert meggyozobb egy (ma mar) Acquia dolgozo irasa, mint egy 3 eve irt komment. :)
főleg tudjukkitől :D
főleg tudjukkitől :D
és nyilván
a sztorinak nincs ott vége, hogy átállítod a péhápémájadminba' a táblákat innoDBre, mert ha igen, akkor ne csodálkozz, ha véletlenül mégse gyorsabb de többet eszik :)
https://skitch.com/aboros/rtdt2/migrating-your-site-to-pressflow-and-inn...
-
clear: both;
ezt ninja meg lipilee is
ezt ninja meg lipilee is megírta már itt a drupal.hu-n
---
Tévedni mindenkinek szabad, csak a mérnöknek észre kell vennie.
Kedves EditH! Legyél kedves
Kedves EditH!
Legyél kedves ne egy 2008-as hozzászólásból idézz (2011-ben!!!!!) (ami már akkor is LOL volt), hanem konkrét mérésekkel, statisztikákkal támaszd már alá miért is jó az, hogy minden egyes műveletnél TABLE LOCKING (segítsek abban, hogy mi ez?) van.
@kérdésfeltevő:
hasznald a memcache-t, nagyon sok dbmüveletet megtakarit (esetleg a sessionok is lehetnek memcacheben). Ha nem kell anonim session, akkor drupalrol valts pressflow-ra.
soksikert.
mivel EditH privátban válaszolt...
"Kedves csy!
Nem értem ezt az ellenséges, sértegető hozzászólást: http://drupal.hu/forum/drupal-gyors%C3%ADt%C3%A1s-ismeretlen-k%C3%A9rd%C... Nem idéztem, csak belinkeltem azzal, hogy "korántsem ilyen egyértelmű". Nem azt mondtam, hogy nincs igaza aborosnak, hanem azt, hogy ez nem ilyen egyszerű kérdés, utána kell olvasni, végig kell gondolni.
Egyébként te sem indokolod meg, hogy Hodicska Gergely 3 évvel ezelőtti hozzászólása a Weblaboron (és az általa ajánlott Pro MySQL könyv) miért is volt LOL 3 évvel ezelőtt. Várjuk a Weblaborra, Drupal.hu-ra ezzel kapcsolatos nagyívű cikkedet.
--cutted--
"
Üdv,
Illyés EditH
Kedves EditH
3 éves dolgot idézel. Tudod, az informatika olyan, hogy minden nap változik. Tegnap még az 5Mb-s merevlemez volt meglepő, ma már a több Peta-s rendszerek sem elérhetetlenek. Olvasni kell és fejlődni, akinek nem megy, az kihal, mint a kis cuki dinoszauruszok. Ahogy látom, te megálltál egy szinten és nem igazán megy a fejlődés. Az Inno -t részben a MyIsam hulyesegei miatt kezdték el fejleszteni és fejlesztik a mai napig. Nem egy forkja született (XtraDb), amit elég nagynevű programozók készítenek (Peter Zaitsev, Vadim Tkachenko).
A MyIsaM csinál egy nagyon csúnya dolgot... Lockol. A lockolt táblában nem végezhetsz műveletet addig, amig a lock feloldásra nem kerül, így szép sorban fognak állni az adatbáziskérések addig, amíg az előttük levő nem végez. Ez egy összetettebb keresésnél igencsak hátrányos. Inno-ban ezzel szemben csak a sor kerül lockolásra, ami jelentősen felgyorsítja az eseményeket (sőt, itt két fajta lock lehetséges...).
Mindezek mellett az inno tuningolására elég sok lehetőséged van, kezdve az io capacitytől, az iró-olvaso szalak szaman at, a filerendszer bufferelésig.
Ezek után várom az indokolt válaszod, hogy miért is MyIsam.
xoxo
Nem olvastam végig a
Nem olvastam végig a weblaboros thread-et, de Felhőnek igaza van abban az esetben, ha kiterjesztett beszúrást alkalmaz MyISAM-nál (tömeges beszúrás egy INSERT INTO-val). Nyilván ez Drupal esetében nem áll meg.
A Memcached azért annyira nem egyértelmű, sokszor meglepő eredményeket tud produkálni, ha kihagyod a hálózati stacket és mmap()-pel gyorsított fájlokat használsz. Hasonló okokból tud bizonyos esetekben gyorsabb lenni egy MongoDB-vel hajtott backend, mint a Memcached.
A sértegető hangnemet pedig egy másik fórumon lehet gyakorolni, ez nem arra való.
rendszergazda
Azért bátorkodtam belinkelni a hozzászólást, mert több nagy webhelyen is azt tapasztaltam, hogy nagy méretű (~500.000 - 1.000.000 rekord) search* táblák lehalnak InnoDB-vel. Ha ilyenkor váltok MyISAM-ra, akkor még kb. 50%-kal lehet növelni a táblaméretet. Jellemzően ez olyan webhelyeken jön elő, ahol nagy mennyiségű tartalom van, folyamatosan töltenek fel, viszont ritkán használják a látogatók a keresőt.
Egyébként minden ilyen webhelyemen a MyISAM is csak átmeneti megoldás volt, és előbb-utóbb le kellett kapcsolni a beépített keresőt (helyette javás megoldások, vagy Google Site Search).
D7-ben már alapértelmezett az InnoDB.
Ezek bonyolult elemzést igénylő kérdések, csak arra akartam felhívni a figyelmet, hogy nem lehet ennyi információ alapján egybites válaszokat adni, hogy mitől lassú egy webhely. Van úgy, hogy egyetlen lekérdezés miatt, és aztán annak az egy lekérdezésnek az optimalizálása alá kell rendelni mindent (szélsőséges példa). Itt még azt sem derült ki, hogy valójában teljesítmény vagy skálázási probléma van-e, stb.
Első körben természetesen meg kell csinálni, amit a rendszergazda kért.
EditH Kérlek, könyörgöm, ne
EditH
Kérlek, könyörgöm, ne adj olyan tanácsokat, amik csak rontanak a teljesítményen. Ha te ezt elhiszed, lelked rajta, de másnak ne mondj olyanokat, amitől nemhogy a plafon szakad, hanem az emelet is.
"(~500.000 - 1.000.000 rekord) search* táblák lehalnak InnoDB-vel."
Kérek egy my.cnf-et, mert ebben az esetben
a-kevés cpu
b-kevés ram
c-nem megfelelő raid/hdd
d-hozzánemértés
játszik.
log db: 2millió rekord, gond nelkül kereshető, törölhető, beszúrható, majdnem realtime (0,01-2sec).
Az adatbázisok egyik kritikus eleme az elérés, ezt egyszerűen és olcsón lehet tuningolni: RAM. Ha nem értesz/ért hozzá az aki csinalja, pont ramot nem fog neki adni, mert azt látja, hogy a *** mysql megint megette a memóriát.
és ismétlem magamat:
Felhő hozzászólása 3 éves!!! Nem vehető referenciának 2011-ben.
Ez nem ilyen egyszerű
Az InnoDB valamivel több memóriát eszik tehát az biztos hogy ha X memóriakeretből gazdálkodsz akkor N rekordra már kifut a memóriából (és akkor swappel, el sem indul vagy hasonló) míg a MyiSAM még eldöcög. A megoldás erre nem a MyISAM hanem több memória.
A MyISAM, mint csy helyesen írja (legalábbis a tényt helyesen, a stílusa más tészta) tábla szintű zárolást használ az InnoDB pedig sor szintűt. Tehát, egyszerre egy folyamat fog egy MyISAM táblába írni (más kérdés hogy mennyi ideig tart egy írás művelet -- hacsak nem írsz nagyon sokat egyszerre ebből nem lesz gondod). A MyISAM azért népszerű mert régi MySQL-eken az InnoDB finoman szólva sem volt egy tempós darab és bár kb. öt éve ez már nem gond, ez a legenda máig megmaradt. A másik, míg a MyISAM konfigurálása majdnem mechanikus, az InnoDB-t egyáltalán nem triviális jól beállítani. De ha egyszer megvan, akkor bizony gyorsabb http://tag1consulting.com/MySQL_Engines_MyISAM_vs_InnoDB
yepp. Végre valaki megérti
yepp.
Végre valaki megérti amit mondok.
De nem valamivel többet, hanem sokkal többet. (myisam 1-2G inno több mint 8most)
@chx
sajat tapasztalat eleg sok db után. Eljön az az idő amikor a myisam lockja az idegeidre megy.
Van amikor a sor lock is.
innodb-t sokan ugy konfigolnak, hogy kikommentezik a sort a konfigból. Ez nem elég. Nagyon nem. Ahogy nem elég stock mysql-t használni sem.
Az innohoz érteni kell / olvasni, de meghálálja, nemkicsit.
korlátok
Pontosan, csak a fenti esetben nem tudtunk több memóriát venni (VPS). Saját szerverre kellett költözni, ami jópár hónap volt, és addig is próbálkoztam "eldöcögtetni" a webhelyeket. Sikertelenül egyébként, ahogy jeleztem is. :)
Régi MySQL vagy InnoDB beállításához rendszergazda szaktudás/hajlandóság hiánya – ezek fejlesztői szempontból éppen olyan korlátok lehetnek, mint a kevés memória. Te nagy fejlesztéseken dolgozol, szerintem fogalmad sincs, milyen tárhelyeken kell időnként itt lent az alvégen valamit produkálni. :)
Múlt heti műsor: MySQL 4.1.13, 27 db vegyes, de főleg Drupal 4.7-es webhely, prefixekkel 1177 tábla az adatbázisban. Feladat: készítsem fel az egyik webhelyet egy nagyobb rohamra, mert 48 órán belül indul az óriási reklámkampány. LOL.
ez egy speciális eset amit itt példának hozol
a kérdésfeltevő általános kérdésére az általánosan igaz válasz az, hogy legyen minden innoDB. megfelelően konfigurálva gyorsabb lesz sokkal. hogy pontosan mi lesz a megfelelő konfiguráció, azt az adott drupal fogja meghatározni. ennek utána lehet olvasni, hogy milyen méretekre kell figyelni, mi mekkora legyen, stb, tele van a net ilyen scriptekkel is, amik javaslatokat tesznek.
felhőnek meg lehet igaza van egy xy speciális igényekkel bíró alkalmazás esetén, de ez egy drupal fórum úgyhogy itt most az ránk nem vonatkozik.
-
clear: both;
ne ész nélkül
A hozzászólásom címe az volt, hogy "kevés az információ". A hozzászólás üzenete pedig annyi, hogy nem lehet 100%-ig biztosra mondani, hogy az InnoDB-re váltás jót fog tenni. Ne essen ész nélkül neki az adatbázisnak – ennyi, nem több, amit mondani akartam. Aki akarta, meghallotta, aki pedig bele akar magyarázni ebbe mást, azon én nem tudok segíteni.
apc
Az apc is segit, nezzetek meg, hogy mennyi cache van es hogy van kihasznalva.
---
http://drupalaton.hu
álljunk meg egy szóra
Egy, nagyon remélem a fenti urat bannolták a drupal.hu-ról mivel magánlevelet webre idézni a feladó beleegyezése nélkül erre igen alapos okot ad. (S nem arról van szó hogy ez a levél olyan baromi nagy tiitok lenne, egyszerűen egy alapelvet áthágtál.)
Kettő, "a drupal6 DB alapú cacheit lődd ki, mert azok lassítják meg penetráns módon az oldalt a béna keresésekkel (szerk.: nagyon) nagy táblákon, helyette legyen file alapú. (kategóriákkal gyorsabb)"
Ha egy fájl backendet használnánk minden cache-re (a mondatban többes számú cache van, tehát nem csak a page cache-ről van szó amit érdemes lehet fájlba tenni mert akkor PHP nélkül lehet a weboldalt kiszolgálni, lásd boost module -- de csak akkor tehát boost nélkül felejtős) akkor megfelelő fájlrendszer esetén ugyan a cid alapú keresés lehet kb. azonosan gyors mint a btree alapú indexeket használó adatbázis lekérdezése viszont kategóriákkal gyorsabb még véletlenül sem, ez csak akkor lehetséges ha az adatbázis rosszul van konfigurálva. De a szemétgyűjtés logikával mindenképpen gondok lesznek ha kellően sok fájl van... a mag (többek között) ezért sem használ fájl alapú cachelést.
Lehetőségnek ott van még,
Lehetőségnek ott van még, hogy felhasz az ember a kattintgatós programozással (site-building) és az azt megvalósító testes modulokat kihajigálja. Views, Panels, Rules és társai kiváltásával, speciális megoldások alkalmazásával lehet igazán gyors dolgokat megvalósítani.
Views, Panels gyorstár
A Views + Panels esetenként nagyon hasznos teljesítmény-optimalizálási eszköz lehet, mivel egészen aprólékosan, akár node mező szinten lehet a gyorstárazást hangolni.
Tervben van egy cikksorozatom
Tervben van egy cikksorozatom a témában. Meg fogsz lepődni. :)
Szuper, várom a meglepetést.
Szuper, várom a meglepetést. :) A múltkori előadásod anyaga fent van valahol?