Srovnání rychlosti Admineru a phpMyAdminu
Školení, která pořádám 
Při běžném používání je Adminer opticky mnohem rychlejší než phpMyAdmin. Chtěl jsem tento rozdíl ale i změřit. Jedno srovnání rychlosti sice už existuje, ale to jednak bylo provedeno na starších verzích a jednak neuvádí metodiku, takže není snadno reprodukovatelné.
Testy jsem vytvořil pro Selenium, takže je lze spustit v libovolném prohlížeči. Sám jsem je spustil ve Firefoxu 4.0.1 pod Windows. Použil jsem veřejně dostupnou, středně velkou databázi Sakila pro MySQL. Netestoval jsem všechny operace, ale jen ty běžně prováděné, které jsou pro uživatele nejdůležitější.
| Operace | Adminer 3.2.2 | phpMyAdmin 3.4.1 | Pomalejší |
|---|---|---|---|
| Přihlášení | 0.776 s | 2.487 s | 3,20× |
| Výběr databáze | 0.319 s | 1.308 s | 4,10× |
| Zobrazení struktury tabulky | 0.192 s | 1.092 s | 5,69× |
| Změna sloupce | 1.661 s | 1.851 s | 1,11× |
| SQL příkaz | 1.112 s | 2.553 s | 2,30× |
| Vypsání začátku dat | 0.233 s | 0.912 s | 3,91× |
| Setřídení podle sloupce | 0.248 s | 0.984 s | 3,97× |
| Úprava záznamu | 0.672 s | 1.493 s | 2,22× |
| Celkem | 5.213 s | 12.680 s | 2,43× |
Většina operací trvá v phpMyAdminu dvakrát až pětkrát déle. V součtu je phpMyAdmin pomalejší o 143 %. Důležitou informací je také to, že jsem testy prováděl na lokálním počítači. Při vzdáleném přístupu přes pomalejší linku by rozdíl byl pravděpodobně ještě podstatně vyšší (kvůli většímu objemu přenášených dat u phpMyAdminu).
Testy jsem v obou případech spustil třikrát a použil ten s mediánem celkového času. Budu rád, když testy vyzkoušíte sami v jiných prohlížečích a operačních systémech a o výsledky se podělíte v diskusi.
- Testy pro Adminer
- Testy pro phpMyAdmin
- Selenium Server potřebný pro spuštění testů
- Databáze Sakila
Za možná ještě zásadnější (ale špatně měřitelný) rozdíl považuji to, že zatímco v jednom panelu prohlížeče běží dlouhotrvající operace, tak Adminer si můžete otevřít do druhého panelu a v práci nerušeně pokračovat (například já se často koukám na SHOW PROCESSLIST). To je k nezaplacení. Druhý panel phpMyAdminu na dokončení dlouhotrvající operace totiž čeká.
Diskuse
Bednee:
Ještě do testu zahrň rychlost nakopírování Adminera/phpMyAdmina na server :). Pokud potřebuju udělat změnu v produkční databázi a nemám k dispozici phpMyAdmin na serveru, tak si tam musím nějaký ten nástroj nahrát a potom je jasné, kdo vítězí.Poslední dobou je pro mne i rychlejší nahrát si na server Adminera než hledat na webu hostingu přístupy do phpMyAdmina.
Michal Wiglasz:
Ještě k tomu, když mnohé hostingové phpMyAdminy jsou za třemi hesly, které jsou udělané tak, aby se nedaly uložit v prohlížeči…SEO Konzultant:
a nebo třeba takový export a import databáze, to je teprv mňamka
Cooler:
Ten sloupeček vpravo s procenty je na první pohled nejasný. Doporučil bych spíše "Rychlost admineru": 243%, o 143% rychlšjí anebo 2.43x rychlejší ... :-)
Jakub Vrána 
:
Takhle snadno to nejde. Pokud B je o 143% pomalejší než A, tak to je totéž, jako že A je o 59% rychlejší než B. Záleží totiž na tom, k čemu se ta procenta vztahují. Nic nemůže být rychlejší o víc než 100%, to by to muselo skončit ještě dřív než to začalo.
Sloupeček prostě vyjadřuje, o kolik procent je phpMyAdmin pomalejší než Adminer.
Jakub Vrána : Cooler:
auto1.speed = 100;auto2.speed = 300;
auto2 je 3x rychlejsi
auto2 ma 300% rychlosti auta 1
auto2 je o 200% rychlejsi nez auto 1 :-)
Jakub Vrána :
A přitom auto1 je o 67% pomalejší než auto2.
Jakub Vrána : Cooler:
To jo, to je někde 4. třída ne :-)Ale necháme toho, já prostě chtěl jen poznamenat, že mi přijde lepší (alespoň marketingově) preferovat slovo rychlejší před slovem pomalejší :-)
+ případně si vybrat to nejvyšší číslo :-)
Jakub Vrána :
OK, opravil jsem to na ten násobek, ten je aspoň stejný z obou stran. Díky za tip.
Jakub Vrána : Tharos:
Opravdu nic? A co třeba takové dovolené :)? Ty mé končí dříve než začínají častěji, než by bylo zdrávo :).Jiří Knesl:
Škoda, že to neumím pořádně změřit v aplikaci, cvičně jsem to zkoušel v Sequel Pro (http://www.sequelpro.com/) a přihlášení trvalo cca 0.1 s a všechny ostatní úlohy tak 0.01s.
Já adminerovi fandím, ale nejde mi moc na rozum, proč svět LAMP je jediná oblast programování, s kterou jsem se setkal, kde pro přístup pro databáze se nepoužívají nativní aplikace.
int:
Nemůže to být tím, že mnoho hostingů povoluje připojení k db jen z webserveru a ne od jakéhokoli vývojáře?Martin Hruška:
Pravý důvod je spíš ten, že phpMyAdmin ve světě živoří právě kvůli nativním aplikacím, zatímco v ČR se používá až tolik, že dokonce vznikla potřeba napsat nástroj nový.V zahraničí je běžné, že se můžete připojit "zvenku", dokonce máte k dispozici ssh a další nástroje. Tady dostanete už 20 let ftp přístup a adresu phpMyAdminu a nazdar! Ovšem proč vývojáři na tuhle hru přistoupí to netuším.
Michal Prynych:
Nejen vývojáři, i obyčejní lidé denně přistupují na hru nejdražších telekomunikačních služeb a bankovních poplatků, je to prostě takový český folklór řekl bych.Ale myslím si, že to je skutečně ten důvod, většina hostingů u nás ten vzdálený přístup nepovoluje.
Martin Hruška:
Rozdíl je ovšem v tom, že telefonního operátora či banku si těžko zvolím ze zahraničí. Hosting můžu mít kdekoliv, když zvolím Evropu, uživatelé nemají šanci poznat rozdíl.bene:
Adminer je parádní, chybí mi v něm ale tři věci k dokonalosti. Bohužel bez těchto třech věcí je používaní admineru někdy velmi nepříjemné.1. Nemohu zvolit "název" indexu (nebo jsem alespoň nezjistil jak).
2. Ve struktuře tabulky nejsou výchozí hodnoty. Neustále musím jít do změny struktury a kliknout na zobrazit výchozí hodnoty. Je to hodně otravné. Stačil by nějaký globální checkbox, který by mi to zobrazil a jeho hodnota se uložila do cookies.
3. Ve struktuře tabulky nevidím kodování sloupce text/varchar/... Opět musím do změny struktury tabulky. Stačilo by, kdyby např typ varchar byl podtržen a po najetí se kodování zobrazilo.
Omlouvám se za přízpěvek nevztahující se k rychlosti.
Jakub Vrána :
Díky za podněty.
1. Na co to potřebuješ? Já se přidání políčka pro zadání názvu indexu bráním, protože to lidi budou mít tendence vyplňovat a nenapadne je, že se název zvolí automaticky. V naprosté většině případů by to tedy akorát překáželo. Název indexu se zobrazuje v bublině v seznamu indexů, nastavit ale skutečně nejde.
2. Opět by to podle mě většinou překáželo. Ale přidat to do bubliny je dobrý nápad.
3. Opět se zeptám – k čemu to je dobré? Já kódování používám většinou všude stejné (kromě vícejazyčných tabulek a občasného použití ASCII pro některé sloupce) a když už to chci vidět, tak proto, abych to rovnou opravil. Mírné skrytí je tedy podle mě na místě.
Jakub Vrána : bene:
Je velký rozdíl pracovat s vlastní navrženou databází a databází na hotovém projektu. Tímto bych oddůvodnil 2. a 3. bod.ad1) Je pravda že tento problém řeším jen u jednoho projektu, jehož databáze se kopíruje a dle aplikace se přidávají vlastní sloupce a indexy a core indexy chci mít označeny.
ad2) Nevím kde by to překáželo, kdyby se to dalo jako další sloupec za komentář (místa je hodně a přehlednosti by to neubralo). Často u bool (tinyint 1) je dobré vidět která hodnota je výchozí. Vidět výchozí hodnotu mi příjde jako standartní a z osobních zkušeností velmi využívaná vlastnost. Proč je možnost zadat výchozí hodnotu, když ji nevidím? Já například nepoužívám témeř komentář, neboď název sloupce volím co nejvýstižněji a očekával bych spíše v bublině komentář. Je to prostě otázka komu co více vyhovuje a jak to používá. Od nástroje pro širokou veřejnost bych to ale očekával.
ad3) Taky používám vesměs ascii a utf8, proto buch tot dal do bubliny, jen pro možnost rychlého zjištění/ověření.
Jakub Vrána :
Díky za smysluplnou argumentaci. Výchozí hodnotu jsem přidal do přehledu tabulky (vzhledem k tomu, že je obvykle velmi krátká, tak ne do samostatného sloupce, ale rovnou za typ). Kódování jsem dal jako bublinu. S názvem indexu si to ještě rozmyslím.
Komentáře hodně používám kvůli Adminer Editoru, takže jejich zobrazení se řídí heslem „Jaký pán, takový hrad“.
Jakub Vrána : bene:
Díky, minimálně mě to používání admineru, jehož rychlost a jednoduchost nejvíce oceňuji, velmi zpříjemní (ale věřím, že tuto vlastnost ocení mnoho dalších).Pokud by někdo měl výchozí hodnotu dlouhou, dal by se použít nějaký truncate a celou zobrazit v bublině, ale je otázka jestli to má opodstatnění.
Jinak já se na strukturu tabulky vetšinou dívám jako na "manuál". Můj problém bych přirovnal např. k php a k jeho dokumentaci. Funkce mají výchozí hodnoty, ale v dokumentaci by nebyly uvedeny.
U indexu, pokud je účelem aby se co nejvíce používaly výchozí názvy a nenutilo to lidi vyplňovat, možná by to vyřešil checkbox, který by zobrazil pole pro zadání vlastního názvu. Možnost pojmenovat index mě ale trápilo ze všeho nejméně, přece jen mohu napsat dotaz - ale lenost je lenost ;-)
Vojtěch Semecký:
Jakube, teď jsem ty názvy indexů řešil s kolegou v práci a máme další argument, proč umožnit jejich pojmenování: Nemožnost dodržet firemní coding standards (pro pojmenování indexů).
Jakub Vrána :
Proč ve firemním coding standardu názvy indexů jsou? Čemu to prospívá?
Jakub Vrána : Tomáš Ovesný:
Prospívá to třeba tomu, že ten název má návaznost na použití v aplikaci. Pokud je tam více složených indexů, tak název dopomůže identifikovat, kde a na co se to používá. Rozhodně je to i lepší prvek pro optimalizaci. Jakub Vrána :
Mohl bych vidět nějaký příklad? Co když se index používá na víc místech, jak se potom jmenuje? Co znamená „je to i lepší prvek pro optimalizaci“?
Poznámka: Ptám se proto, abych se něco přiučil. Já jsem nikdy neviděl prakticky žádný smysl v pojmenování indexů, protože index jsem vždy identifikoval podle sloupců, kterými je tvořen. Takže jestli někdo smysl v pojmenování spatřuje, rád se dozvím proč a třeba ho tam potom taky uvidím.
Jakub Vrána : Tomáš Ovesný:
Mně to třeba teď pomáhá při optimalizaci dotazů ze slowlogu.Při explain vidím ty názvy indexů a "trkne" mne, proč někdo tenhle složený index vytvořil.
Samozřejmě to má tu nevýhodu, jak píšete: "Co když se používá index na více místech".
Michal Prynych:
Co třeba FORCE INDEX(název_indexu)? To reálně na Pixmacu používáme u vícesloupcových indexů, sice indexy pojmenováváme na základě názvů těch zúčastněných sloupců, ale teoreticky někdo jiný je může chtít pojmenovat podle sebe, přeci jen jsou to takové proměnné, že jo. Jakub Vrána :
EXPLAIN a FORCE INDEX jsou výborné argumenty, díky za ně. V EXPLAINu mě hloupé názvy indexů taky rozčilují, FORCE INDEX jsem osobně použil jedinkrát (a pak jsem dotaz přepsal na ještě optimálnější variantu, ve které už FORCE INDEX nebylo potřeba), ale chápu, že ho někdo používat může.
Jakub Vrána : Tomáš Ovesný:
Souhlasím s první částí, nesouhlasím s tím, že jsou to takové proměnné, ale vystihuje to tu myšlenku.Vojtěch Semecký:
Tak dobře, jiný argument: jestli má být Adminer plnohodnotný nástroj na správu DB, neměl by umět všechno, co databáze umožňuje, místo toho, aby existenci některých možností utajoval?
Jakub Vrána :
Adminer je plnohodnotným nástrojem tím, že dovoluje vykonat libovolný ručně zadaný SQL příkaz. Ohledně toho, co jde „naklikat“ se naopak držím při zemi a snažím se optimalizovat snadnost použití – příliš mnoho prvků uživatelské rozhraní znepřehledňuje a snadnost použití zhoršuje. Když naopak musím SQL příkaz moc často zadávat ručně, tak to taky snadnost použití zhoršuje.
Takže schopnosti Admineru zcela záměrně omezuji – např. při vytváření pohledu nelze definovat žádné volby, protože se prostě moc často nepoužívají. Když je někdo chce, holt si musí dotaz sestavit ručně.
U názvu indexu vidím zdržovací faktor poměrně značný – v naprosté většině případů ho není potřeba ručně zadávat, ale když už tam pro něj bude políčko, tak ho většina uživatelů bude mít tendence vyplňovat (kromě toho, že to znepřehlední uživatelské rozhraní).
Zajímala by mě ale tvá odpověď i na mou původní otázku (pochopitelně pro ni také platí poznámka, kterou jsem napsal Tomášovi).
Jakub Vrána : Vojtěch Semecký:
Netvrdím, že názvy indexů v coding standards něčemu prospívají. Ale někdy prostě nemáš na vybranou. Jeden příklad z praxe:
Určitě znáš CMS Drupal. Pokud pro něj chceš napsat rozšíření a chceš, aby ti ho vzali do oficiálního repozitáře, tak jejich standardy prostě dodržet musíš. A když se podíváš na http://drupal.org/node/2497 tak se tam dočteš "Index names should begin with the name of the table they depend on, eg. INDEX users_sid_idx."
A můžeš se jich ptát, "Čemu to prospívá?", ale docílíš tím maximálně toho, že ti tvůj plugin nezveřejní.
Jakub Vrána :
Já bych spíš čekal, že se tím dozvím smysl tohoto opatření. Protože nějaký být může a já se rád přiučím. Nebo to třeba mělo nějaký smysl v minulosti a teď už to smysl nemá, takže to povede k odstranění tohoto pravidla. Nebo to napsal nějaký despota, protože mu to prostě připadalo hezké a žádný další smysl to nemá – i z toho se něco dozvím.
Zeptal jsem se na to Marka Sotáka.
Jakub Vrána : Jakub Vrána :
Už jsem na to nejspíš přišel. V neMySQL databázích musí být název indexu unikátní v rámci celého schématu.
Jakub Vrána : Jakub Vrána :
Názvy indexů jsou nyní editovatelné (v Gitu). Funguje to tak, že název indexu se JavaScriptem automaticky sestavuje z názvů sloupců, které ho tvoří. Tím pádem se vytváří lepší názvy indexů než vyrábí MySQL automaticky (protože ta název indexu odvozuje jen z prvního sloupce) a zároveň to uživatele neotravuje (protože název se doplní automaticky, takže nemá tendenci se zdržovat vyplňováním).
V ostatních databázích se název indexu ještě prefixuje názvem tabulky (protože názvy indexů musí být unikátní v rámci celého schématu).
Jakub Vrána : Tomáš Ovesný:
Děkuji!Diskuse je zrušena z důvodu spamu.
© 2005-2024 