Výkonnostní opatření Admineru

Školení, která pořádám

Při vývoji Admineru kladu velký důraz na výkonnost. Co se za tím skrývá?

Co se naopak neprovádí?

Největší vliv na rychlost má ale podle mě ergonomie uživatelského rozhraní, o kterou se snažím. K provedení požadované operace prostě vede co nejmíň kliknutí.

Přijďte si o tomto tématu popovídat na školení Výkonnost webových aplikací.

Jakub Vrána, Adminer, 22.10.2010, diskuse: 21 (nové: 0)

Diskuse

ikona Frodik:

Malý dotaz stranou - můžeme se v blízkém budoucnu těšit na využití některých novinek z HTML5 ? Konkrétně mám na mysli třeba SessionStorage, LocalStorage a IndexedDB. Ty by pro použití Admineru mohli být zajímavé ..

ikona Jakub Vrána OpenID:

Můžeš to prosím trochu rozebrat? Na co by se jednotlivé technologie daly použít?

David Grudl:

Na nic, ale bylo by to cool a fungovalo by to v Chrome :-)

ikona Karel Dytrych:

Já si dovedu představit že by se v admineru dal aktivovat něco jako "offline mode" (třeba i jen pro vybranné tabulky), s tím že by se data databáze stáhli lokálně, uživatel by pracoval a vyvíjel.. a po dokončení prací by to opět synchronizoval na ostrý server.

Věřím že by to využilo plno programátorů při vytváření a úvodní editaci různých webů atd. Rozhodně by to byl však jen doplněk a uživatel by musel vědět co dělá a že si to v ten okamžik "může dovolit".

ikona Jakub Vrána OpenID:

Vždyť když něco vyvíjím, tak potřebuji kompletní kopii struktury databáze, kterou můžu využívat i ve vyvíjené aplikaci, ne jen nějakou její virtuální podobu v Admineru. A když to potřebuji nahrát zpátky, můžu použít ALTER export, který Adminer nabízí.

Navrhované použití by se hodilo snad jen pro uživatele, kteří s databází nepotřebují pracovat zvenku Admineru a těch asi opravdu nebude moc.

ikona Karel Dytrych:

To ja take.. ja pouzivam desktop aplikace typu SQLyog... ale tak z nekolika nemalo rozhovoru s vyvojari na hostingu mam pocit ze by se jim nekdy siklo kdyby si dali treba clanky do "offline modu" a upravovali dle libosti nebo kdyby si zalozili DB "offlinove", v ni si naklikali plno veci a pak jen klikli na synchro...

Je jasne ze pres Alter apod. to jde take. A urcite je fakt, ze je to hromada prace pro mensinu, takze to delat urcite nebudete.. Ale prijde vam ta myslenka uz od zakladu spatna?

ikona Jakub Vrána OpenID:

Smysl by to mohlo dávat v Adminer Editoru, kde může být takovýhle scénář přirozený. Ale pak se najednou musí řešit i problémy synchronizace – že někdo změnil data během toho, co jsem je editoval i já. Do toho se pouštět nebudu.

Emil:

Nic ve zlém příteli, ale raději si nejprve opravte Váš web (co stránka to notfound) a pak navrhujte featury Admineru..

ikona Frodik:

Ona moje stranka ma s adminerem nejakou souvislost ?

ikona Aichi:

pokud to nebylo plácnutí do větru, tak mohl myslet to, že by s ním šlo pracovat offline, jako natáhnout vše?? do paměti, a kdyby ses náhodou odpojil, tak by se to zaznamenalo lokálně, dokud by ses nepřipojil.

ikona Frodik:

Ano, offline mód mě taky napadl.

Co jsem měl přímo na mysli - Při každém načtení stránky by se nemusely přenášet údaje o tabulkách, stačilo by je načíst jen jednou a používat lokální cache, která by sesynchronizovala jen na základě jejich úprav (vytvoření tabulky, úpravy tabulky a smazání). A jelikož by se tyto údaje přenášely jen při prvním načtení, tak by nebylo od věci načíst i tabulky ze všech databází na serveru. Tím pádem by přepínání mezi databázemi nemuselo nutně znamenat refresh stránky, stačil by zobrazit tabulky změněné databáze Javascriptem.

Jako cool feature bych bral uložit si některé oblíbené/často používané dotazy do lokální cache. Je pravda, že by to znamenalo si je uložit ještě někde jinde (jiný prohlížeč, jiné PC, vymazání cache, atd..), ale byly by aspoň na jednom počítači u kterého člověk nejvíc sedí, hned po ruce.

ikona Jakub Vrána OpenID:

U toho narážíme na tradiční problém kešování – když se nakešovaný obsah změní, tak se musí refreshnout. A změnit se může bez jakéhokoliv varování.

To už bych raději použil starý dobrý AJAX – při vybraných operacích se obnoví jen vnitřek stránky a navigace zůstane stejná.

Co se oblíbených dotazů týče, dají se uložit normálně do bookmarků. Využívá to například odkaz Upravit u SQL příkazu zobrazeného ve výpisu dat.

ikona Frodik:

ad "tradiční problém kešování" - v případě admineru ale lze poměrně dobře odhadovat jestli došlo ke změně struktury DB a tabulek. Pokud prováděný dotaz obsahuje "drop, alter, create, ..." tak se s aktuální stránkou pošlou data s novou strukturou. Takže toto bych nepovažoval za problém vyřešit.

Jediný problém, co zůstává z mého pohledu je situace kdy databázi spravuje více lidí současně (většinou je jeden správce DB, za mé praxe jsem se nesetkal s tím, že by byli 2 a nebo více správců jedné databáze). To by se dalo zase docela elegantně řešit zobrazením stavu v rozhraní Admineru, že je přihlášen další uživatel nebo uživatelé z daných IP adres (stejně jako to třeba dělá Gmail). Ve chvíli, kdy víme, že tento stav nastal, tak se buď Adminer může přepnout sám nebo se zeptat, zda se má přepnout do režimu "online", tedy stavu, kdy se při každém requestu bude přenášet informace o struktuře DB a tabulek, tedy současný stav.

ikona Jakub Vrána OpenID:

Nezdá se mi, že by to byl ten správný směr, kterým by se vývoj měl ubírat. Navíc si ani moc dobře neumím představit, jak by to fungovalo s vypnutým JS.

Mnohem lepší mi přijde ten AJAX, který má snadný bez-JS fallback, nepotřebuje žádnou keš a při refreshi stránky prostě stáhne seznam tabulek znovu. V neposlední řadě funguje ve všech prohlížečích.

Seznam tabulek se může změnit i mimo Adminer. Dost už, že se kešuje seznam databází (jehož získání je opravdu velmi pomalé). Seznam tabulek se naopak získá rychle.

ikona Frodik:

No myslel jsem to jako dobrý námět na zlepšení, ale nevěděl jsem, že bez-JS fallback je předpokladem pro jeho tvorbu.

Jen tak ze zajímavosti, jaké množství uživatelů Adminer používá v shellu přes links ? Nebo je jiný možný příklad, kde by mohl běžet bez podpory JS ? A pokud si někdo vypíná JS v klasickém prohlížeči, tak to upřímně nechápu ...

ikona Jakub Vrána OpenID:

Řeknu to naopak – neznám jediný důvod, proč by Adminer s vypnutým JS neměl fungovat.

ikona Frodik:

Ok, beru to jako rozhodnutí autora, ikdyž já osobně s ním nesouhlasím :-)

To využití cool feature je ale nepřeberné, co třeba zmíněný offline mód ? Mějme příklad, kdy na špatném připojení či slabé baterce v Admineru píšu náročný dotaz (nebudu brát v potaz, že bych měl mít baterku nabitou a připojení kvalitní). Dojde mi baterka těsně před odesláním dotazu nebo při jeho odeslání mi vypadne wifi signál. O dotaz tím pádem přijdu. Kdyby se využila lokální cache, mohl by se tento dotaz průběžně ukládat jako draft a o dotaz bych tak nepřišel.

ikona Jakub Vrána OpenID:

Řešit došlou baterku opravdu nebudu. Adminer asi nebudou zadávat žádní ťulpíci, kterým by se to běžně stávalo. A s vypadlým připojením žádný problém není. Stačí po jeho nahození stránku obnovit.

ikona v6ak:

A vybitou baterku řeší automatická hibernace, je-li povolena a je-li dostatečně velký swapák.

Ale jestli chceš, můžeš napsat nějaký doplněk.

cucací potřeby:

Ahoj, Jakube.
> K provedení požadované operace prostě vede co nejmíň kliknutí.

To mi připomnělo - nezměnil jsi názor sjednocení řádku s tabulkovými odkazy i na stránky "Pozměnit tabulku" a "Nová položka"? (Tam výše uvedená věta zatím neplatí.)

ikona Jakub Vrána OpenID:

Měl jsem v plánu něco jiného – přidat tyhle odkazy ke všem tabulkám v navigaci. Ale výsledek se mi moc nelíbil. http://github.com/vrana/adminer/tree/navigation_commands

Diskuse je zrušena z důvodu spamu.

avatar © 2005-2024 Jakub Vrána. Publikované texty můžete přetiskovat pouze se svolením autora. Ukázky kódu smíte používat s uvedením autora a URL tohoto webu bez dalších omezení Creative Commons. Můžeme si tykat. Skripty předpokládají nastavení: magic_quotes_gpc=Off, magic_quotes_runtime=Off, error_reporting=E_ALL & ~E_NOTICE a očekávají předchozí zavolání mysql_set_charset. Skripty by měly být funkční v PHP >= 4.3 a PHP >= 5.0.