Naštěstí to obvykle neznamená.
Chybějící proměnná ve vaší rovnici je, jak vaše databáze a váš aplikační server a cokoli jiného ve vašem zásobníku zpracovává souběh .
Abych to ilustroval striktně z pohledu MySQL, napsal jsem testovací klientský program, který naváže pevný počet připojení k serveru MySQL, každé ve svém vlastním vláknu (a tak je schopen zadat dotaz serveru přibližně ve stejnou dobu) .
Jakmile všechna vlákna zpětně signalizují, že jsou připojena, je všem současně odeslána zpráva k odeslání jejich dotazu.
Když každé vlákno dostane signál „go“, podívá se na aktuální systémový čas a poté odešle dotaz na server. Když dostane odpověď, znovu se podívá na systémový čas a poté odešle všechny informace zpět do hlavního vlákna, které porovná načasování a vygeneruje výstup níže.
Program je napsán tak, že nepočítá čas potřebný k navázání spojení se serverem, protože v dobře fungující aplikaci by spojení byla znovu použitelná.
Dotaz byl SELECT SQL_NO_CACHE COUNT(1) FROM ... (tabulka InnoDB s asi 500 řádky).
vlákna 1 min 0,001089 Max 0,001089 AVG 0,001089 Celkový běh 0,001089. Vlákna 16 min 0,001222 Max 0,005142 AVG 0,002707 Celkový běh 0,005591threads 32 min 0,001187 Max 0,010924 AVG 0,003786 Celkový běh 0,014812threads 64 min.
Časy jsou v sekundách. Min/max/avg jsou nejlepší/nejhorší/průměrné časy pozorované při stejném dotazu. Při souběžném počtu 64 si všimnete, že nejlepší případ nebyl až tak odlišný od nejlepšího případu pouze s 1 dotazem. Největším přínosem je zde ale sloupec celkové doby běhu. Tato hodnota je rozdíl v čase od doby, kdy první vlákno odeslalo svůj dotaz (všechny odesílají svůj dotaz v podstatě ve stejnou dobu, ale „přesně“ ve stejnou dobu je nemožné, protože nemám 64jádrový stroj, který by spustil testovací skript zapnut) do okamžiku, kdy poslední vlákno obdrželo odpověď.
Postřehy:Dobrou zprávou je, že 64 dotazů trvajících v průměru 0,005586 sekund rozhodně nevyžadovalo k provedení 64 * 0,005586 sekund =0,357504 sekund... nevyžadovalo ani 64 * 0,001089 (v nejlepším případě) =0,069696 z těchto dotazů bylo zahájeno a dokončeno během 0,019841 sekund... nebo pouze asi 28,5 % času, který by teoreticky trvalo, než by se spouštěly jeden po druhém.
Špatnou zprávou samozřejmě je, že průměrná doba provádění tohoto dotazu při souběžnosti 64 je více než 5krát delší než doba, kdy je spuštěn pouze jednou... a v nejhorším případě je téměř 14krát vyšší. Ale to je stále mnohem lepší, než by naznačovala lineární extrapolace z doby provedení jednoho dotazu.
Věci se však neškálují donekonečna. Jak vidíte, výkon se souběžně zhoršuje a v určitém okamžiku by to šlo z kopce - pravděpodobně poměrně rychle - jak bychom dosáhli toho, které úzké místo nastane dříve. Počet tabulek, povaha dotazů, jakékoli uzamčení, na které narazíte, to vše přispívá k tomu, jak server funguje při souběžném zatížení, stejně jako výkon vašeho úložiště, velikost, výkon a architektura paměti systému a vnitřnosti MySQL – některé z nich lze vyladit a některé ne.
Ale databáze samozřejmě není jediným faktorem. Způsob, jakým aplikační server zpracovává souběžné požadavky, může být další velkou součástí vašeho výkonu při zatížení, někdy ve větším rozsahu než databáze a někdy méně.
Jedna velká neznámá z vašich benchmarků je, kolik z tohoto času stráví databáze odpovídáním na dotazy, kolik času tráví aplikační server prováděním logiky a kolik času tráví kód, který je vykreslení výsledků stránky do HTML.