Na szczęście zwykle tak nie jest.
Brakująca zmienna w równaniu to sposób, w jaki Twoja baza danych i Twój serwer aplikacji i wszystko inne w twoim stosie obsługuje współbieżność .
Aby zilustrować to ściśle z perspektywy MySQL, napisałem program klienta testowego, który nawiązuje stałą liczbę połączeń z serwerem MySQL, każde we własnym wątku (a więc jest w stanie wysłać zapytanie do serwera mniej więcej w tym samym czasie). .
Gdy wszystkie wątki zwrócą sygnał, że są połączone, wiadomość zostanie wysłana do wszystkich w tym samym czasie, aby wysłać zapytanie.
Kiedy każdy wątek otrzymuje sygnał "go", sprawdza aktualny czas systemowy, a następnie wysyła zapytanie do serwera. Po otrzymaniu odpowiedzi ponownie sprawdza czas systemowy, a następnie wysyła wszystkie informacje z powrotem do głównego wątku, który porównuje czasy i generuje poniższe dane wyjściowe.
Program jest napisany w taki sposób, że nie liczy czasu potrzebnego do nawiązania połączenia z serwerem, ponieważ w dobrze działającej aplikacji połączenia byłyby wielokrotnego użytku.
Zapytanie to SELECT SQL_NO_CACHE COUNT(1) FROM ... (tabela InnoDB zawierająca około 500 wierszy).
threads 1 min 0.001089 max 0.001089 avg 0.001089 total runtime 0.001089
threads 2 min 0.001200 max 0.002951 avg 0.002076 total runtime 0.003106
threads 4 min 0.000987 max 0.001432 avg 0.001176 total runtime 0.001677
threads 8 min 0.001110 max 0.002789 avg 0.001894 total runtime 0.003796
threads 16 min 0.001222 max 0.005142 avg 0.002707 total runtime 0.005591
threads 32 min 0.001187 max 0.010924 avg 0.003786 total runtime 0.014812
threads 64 min 0.001209 max 0.014941 avg 0.005586 total runtime 0.019841
Czasy są w sekundach. Minimalna/maksymalna/średnia to najlepsze/najgorsze/średnie czasy zaobserwowane podczas wykonywania tego samego zapytania. Przy współbieżności 64 można zauważyć, że najlepszy przypadek nie różnił się aż tak bardzo od najlepszego przypadku z tylko jednym zapytaniem. Ale największym wnioskiem jest tutaj kolumna całkowitego czasu działania. Ta wartość jest różnicą w czasie od momentu wysłania zapytania przez pierwszy wątek (wszyscy wysyłają swoje zapytanie w zasadzie w tym samym czasie, ale "dokładnie" w tym samym czasie jest niemożliwe, ponieważ nie mam 64-rdzeniowej maszyny do uruchomienia skrypt testowy włączony) do momentu, w którym ostatni wątek otrzymał odpowiedź.
Obserwacje:dobrą wiadomością jest to, że 64 zapytania zajmujące średnio 0,005586 sekundy zdecydowanie nie wymagały wykonania 64 * 0,005586 sekundy =0,357504 sekundy... nie wymagało nawet 64 * 0,001089 (najlepszy czas) =0,069696 Wszystkie z tych zapytań zostało rozpoczętych i zakończonych w ciągu 0,019841 sekundy... czyli tylko około 28,5% czasu, jaki teoretycznie zajęłoby im wykonanie jednego po drugim.
Złą wiadomością jest oczywiście to, że średni czas wykonania tego zapytania przy współbieżności 64 jest ponad 5 razy dłuższy niż czas, gdy jest uruchamiany tylko raz… a najgorszy przypadek jest prawie 14 razy dłuższy. Ale to i tak jest znacznie lepsze niż sugerowałaby liniowa ekstrapolacja z czasu wykonania pojedynczego zapytania.
Jednak rzeczy nie skalują się w nieskończoność. Jak widać, wydajność pogarsza się wraz ze współbieżnością i w pewnym momencie spada – prawdopodobnie dość szybko – ponieważ osiągnęliśmy wąskie gardło, które wystąpiło jako pierwsze. Liczba tabel, charakter zapytań, wszelkie napotkane blokady wpływają na działanie serwera przy jednoczesnym obciążeniu, podobnie jak wydajność pamięci masowej, rozmiar, wydajność i architektura pamięci systemowej oraz wewnętrzne elementy MySQL — niektóre z nich można dostroić, a inne nie.
Ale oczywiście baza danych nie jest jedynym czynnikiem. Sposób, w jaki serwer aplikacji obsługuje współbieżne żądania, może być kolejną dużą częścią wydajności pod obciążeniem, czasami w większym stopniu niż baza danych, a czasami w mniejszym.
Jedną wielką niewiadomą z twoich testów porównawczych jest to, ile czasu zajmuje baza danych odpowiadając na zapytania, ile czasu serwer aplikacji zajmuje wykonanie logiki biznesowej, a ile czasu zajmuje kod, który jest renderowanie wyników strony do HTML.
