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ší.

OperaceAdminer 3.2.2phpMyAdmin 3.4.1Pomalejší o
Přihlášení0.776 s2.487 s3,20×
Výběr databáze0.319 s1.308 s4,10×
Zobrazení struktury tabulky0.192 s1.092 s5,69×
Změna sloupce1.661 s1.851 s1,11×
SQL příkaz1.112 s2.553 s2,30×
Vypsání začátku dat0.233 s0.912 s3,91×
Setřídení podle sloupce0.248 s0.984 s3,97×
Úprava záznamu0.672 s1.493 s2,22×
Celkem5.213 s12.680 s2,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.

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á.

Jakub Vrána, Adminer, 30.5.2011, diskuse: 35 (nové: 0)

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ší ... :-)

ikona Jakub Vrána OpenID:

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.

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 :-)

ikona Jakub Vrána OpenID:

A přitom auto1 je o 67% pomalejší než auto2.

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 :-)

ikona Jakub Vrána OpenID:

OK, opravil jsem to na ten násobek, ten je aspoň stejný z obou stran. Díky za tip.

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.

ikona Jakub Vrána OpenID:

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ě.

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í.

ikona Jakub Vrána OpenID:

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“.

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ů).

ikona Jakub Vrána OpenID:

Proč ve firemním coding standardu názvy indexů jsou? Čemu to prospívá?

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.

ikona Jakub Vrána OpenID:

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.

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.

ikona Jakub Vrána OpenID:

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.

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?

ikona Jakub Vrána OpenID:

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).

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í.

ikona Jakub Vrána OpenID:

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.

ikona Jakub Vrána OpenID:

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.

ikona Jakub Vrána OpenID:

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).

Tomáš Ovesný:

Děkuji!

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.