Drupal 6 mnohem pomalejší než Drupal 5. Existuje řešení?
Asi rok používám na některých webech Drupal 5, před půlrokem jsem někde nasadil Drupal 6. Všiml jsem si velikého zpomalení oproti Drupal 5.
Zkoušel jsem to měřit modulem Devel a Drupal 5 mi všemožné stránky načítá do 300 ms.
Drupal 6 mi načítá i jednoduchý web někdy i pár vteřin, jindy třeba „jen“ 500ms. Tristní to je při otevření administrace (až deset vteřin) a korunu tomu nasazuje otevření stránky modulů, zde je možné jít až do minuty (Page execution time was 30420.83 ms. Memory usage: Memory used at: devel_init()=1.35 MB, devel_shutdown()=32.34 MB). Jsou i vysoké nároky na paměť.
Liší se to hosting od hostingu, momentální zkušenosti jsou ze serveru 300 MHz, 256 MB RAM, kde je to spíše lepší, přesto platí výše zmíněné údaje.
Je to u Drupalu 6 normální? Jaké má tento systém nároky, existují cesty jak tyto problémy eliminovat, nebo je to prostě nějak zabugované?
Takto nevidím jako možné zůstávat u Drupalu 6 a budu muset „updatnout“ opět na Drupal 5 :(.
Hlavní RSS kanál
Ano, novsi Drupal je pomalsi
Ano, novsi Drupal je pomalsi nez predchadzajuca verzia. Riesilo sa to na drupal.org. Drupal 7 preto prinesie niekolko noviniek, ako napriklad viacero poziadaviek na db cez na jedno napojenie.
Ale to co pises je az privelky narast, respektive prepad. Takze hladal by som chybu niekde inde. Prebehni si moduly ktore pouzivas ,ci tma nie su nejake vykonnostne zmeny, alebo ci nemas nejake konflitky niekde, pripadne ci sa ti nenacita nieco externe a podobne.
admin/build/module (a dalsi)
admin/build/module (a dalsi) pri navstiveni kontrolujou jestli je nejaky update pro modul, da se to vypnout v nastaveni
btw updatu na nizsi verzi se rika downgrade ;)
Prošel jsem různé
Prošel jsem různé návody. Ten update mám zakázaný, přesto je to jak říkám. A update mám v uvozovkách, kontext je pochopitelný…
Na jednom hostingu s tím
Na jednom hostingu s tím mám hodně velký problém, viz http://www.drupal.cz/…uild-modules
Stačí admin-menu, CCK a Views a už to skoro nechodí… Vypnutí modulu update status to neřeší, ani navýšení memory limitu…
Nehledě na rozdíly podle hostingu by mě fakt zajímalo, jestli 3–4 tis. dotazů do databáze na načtení stránky s administrací modulů je v pořádku???
3–4k? WTF?!!! Okamizte di
3–4k? WTF?!!! Okamizte di nahod devel!
Ano a nejsem zdaleka sama
Ano a nejsem zdaleka sama (http://drupal.org/node/311626), co vyhodil devel už jsem tady do fóra psala viz odkaz výše, co s tím dál nevím (jen musím bohužel dodat že tabulkami a myisam to v mém případě není). Kolik dotazů do databáze máte na této stránce vy (na D6)?
Aha, sry. Pri stranke
Aha, sry. Pri stranke s modulmy je to normalne. Ja mam „Executed 4026 queries in 1541.25 milliseconds.“ Zalezi od toho, kolko mas modulov. Pomale nacitanie stranky s modulmy nie je problem, ale(logicka) vlastnost/spravanie :)
V Drupalu 6 pod 10 sekund
V Drupalu 6 pod 10 sekund na stránce /admin/build/modules? Tak to bych chtěl mít taky :-)
Imho drtivá většina uživatelů na drtivé většině webhostingách či na svém vlastním PC se na této stránce nedostane určitě pod 10 sekund, spíše se čas pohybuje mezi 20 až 40 sekundami.
No, dobrá, dejme tomu, že se v průměru web generuje cca 30 sekund a že na té website je cca 90 modulů, i když v praxi je obvykle méně. To by znamenalo, že každý modul v průměru Drupal zpracovává děsných 333 ms. Sice jsem modul který má na starosti tu stránku s moduly nezkoumal, ale imho popisy a závislosti Drupal vytáhne z *.info souborů (1 malý soubor na 1 modul) a teoreticky by na zjištění které moduly jsou zapnuté stačil celkem 1 sql dotaz. Dále pokud to kontroluje nové verze modulů z nějaké cache v sql databázi, i tak by měl stačit 1 dotaz na 1 modul a pokud to kontroluje nové verze přes internet, měla by jít tato kontrola vypnout. Navíc v Drupalu 5 se tato stránka generuje podstatně rychleji, třeba 200 ms, nemluvě o jiných redakčních systémech. Takže určitě bych tuto vlastnost nenazýval logickou. Jinak vím, že praxe bývá těžší než teorie, prakticky se totiž ještě musí vygenerovat html tabulka a tak, ale i to by mělo být bleskové, určitě pod 1 sekundu. Tak a teď mi někdo vysvětlete kde je v mé úvaze logická či praktická chyba :-) A hlavně co konkrétně na té stránce žere tolik času.
opera mi napocitala 4sekundy
opera mi napocitala 4sekundy – vcetne odeslani a prijeti dat. a to tam mam cck, views, date, calendar apod.
Drupal.cz i ostatni weby
Drupal.cz i ostatni weby cca 3 sec
Drupal.cz už jede na Drupal
Drupal.cz už jede na Drupal 6?
Od 20.3. uz ano
Od 20.3. uz ano
Problém se v mém případě
Problém se v mém případě vyřešil (pokud jsem správně pochopila z údajů od hostingu) přesunem na jiný server. Bohužel k tomu neumím říct nic podrobnějšího. Teď to chodí (admin/build/modules) pod těch 10 sec. vždy.
Treba pohladat co by tomu
Treba pohladat co by tomu pomohlo – je na webe nejaka bytecode cache (APC, eAccelerator)? Je dostatocne velke nastavenie query cache pre mysql? A tiez zalezi na tom ci tam nebezi dalsich 100 aplikacii z narocnymi PHP skriptami… Danom za modularnost Drupalu je narocnostna databazu (hlavne v administracii). Nedavno som sa zaoberal optimalizovanim jedneho webu a vyslo mi z toho ze pokial sa zapne zakladna drupal cache je zobrazovanie stranok velmi rychle ale po prihlaseni to je zasa dost pomale.
Vsetky tie velke weby to riesia kesovanim, ze im to stiha 10 stranok za sekundu… Na beznom hostingu z narocnejsou strankou to ale moze byt problem.
Co se cache týče, je podle
Co se cache týče, je podle mně právě problém s tím, že ne vše lze cachovat, viz např. jak píšeš, že po přihlášení byl web dost pomalý a i kdyby se podařilo cachovat opravdu skoro všechno (i když zrovna třeba stránka s moduly imho asi moc cachovat nepůjde), mohlo by to imho působit problémy při aktualizaci modulu, ruční úpravě modulu nebo theme, nemluvě o vývoji vlastního modulu při zapnuté cache. Imho cache je dobrá na funkční zaběhlý web s vysokou návštěvností na kterém se potřebují přihlašovat snad jen redaktoři a administrátor jen vyjímečně něco přenastavuje. A to není případ většiny webů nemluvě o stavu, když jsou ve vývoji.
Takže jaké existuje jiné řešení než cache (či downgrade na Drupal 5 či počkání na Drupal 7)?
No ked mas hotove weby ako
No ked mas hotove weby ako si pisal tak zapni cache a mas po problemoch. Je jasne ze zakladna cache nepomoze vzdy ale su rozne cache moduly ktore dokazu kesovat len casti stranky (napriklad kesovanie blokov je v zaklade uz v D6 aktivovane akurat z nejakeho dovodu pren neexistuje administracia – co riesi tusim nejaky extra modul – v D5 to bolo Block cache). Pri vyvoji je samozrejme dobre mat kes vypnutu – ja pouzivam z admin menu pomerne casto moznost zmazat kes (ked robim nejake zmeny).
Riesenie existuju – aktivovane APC (alebo eAccelerator)… Pokial to doteraz aktivovane nebolo spozorujes urcite rychlejsiu odozvu webu. Vsetko je to o vhodnej konfiguracii.
Pomalý web
Mám rozestavěný web s e-shopem na D6 a jsem s pomalým načítáním docela v koncích. Je to čím dál pomalejší a dneska mi to úplně chcíplo při nahrávání obrázku kategorie (tzv. blank screen of death).
Devel hlásí na admin stránkách běžně přes 40.000ms /page exec. time/ a titulka (na které mimochodem nic není) 21.000ms.
Opravdu bych ocenila řešení, třeba i zaplatím, protože 1. května otevírám a musím rychle stavět.
Pozrel by som sa este na
Pozrel by som sa este na pocet sql na tych strankach. Mne sa to podarilo zrazit pre neprihlaseneho na cca 60 sql na stranku ale pri prvotnom generovani to bolo aj cez 250.
SQL mám asi 230 (pro admina)
SQL mám asi 230 (pro admina)
Este ich dlzka by bola
Este ich dlzka by bola zaujimava – nemali by mat viac ako niekolko desiatok ms, vacsinou do 10ms…
Délka dotazů
Objevuje se mi asi 10 dotazů, které mají přes 10ms – cache_set tam figuruje hned několikrát nejhorší s 90ms, pak taky module_list, module_rebuild_cache, to je na adminských stránkách.
Titulka zase ukazuje přes 100ms list_themes, variable_set, cache_clear_all, language_list, drupal_lookup_path je tam 2×. Celkem mi ukazuje devel na titulce víc než 20 dotazů přes 10ms.
Poslat nový komentář