Jak skalować php5 + MySQL powyżej 200 żądań na sekundę?

Poprawiam swoją stronę główną pod kątem wydajności, obecnie obsługuje ona około 200 żądań na sekundę w 3.14.by, która zjada 6 zapytań SQL, i 20 req / sekundę w 3.14.by/forum, które jest forum phpBB.

O dziwo, liczby są prawie takie same na niektórych serwerach VPS i dedykowanym serwerze Atom 330.

Oprogramowanie serwera to: Apache2 + mod_php prefork 4 childs (tutaj wypróbowano różne numery), php5, APC, nginx, memcached do przechowywania sesji PHP.

MySQL jest skonfigurowany do zużywania około 30% dostępnej pamięci RAM (~ 150 Mb na VPS, 700 Mb na dedykowanym serwerze)

Wygląda na to, że gdzieś jest wąskie gardło, które nie pozwala mi iść wyżej, jakieś sugestie? (tj. wiem, że wykonanie mniej niż 6 SQLów przyspieszyłoby to, ale nie wygląda to na czynnik ograniczający, ponieważ sqld zjada nie więcej niż kilka% w górę z powodu zapytań buforowanych)

Czy ktoś przetestował, że kopanie gotowego apache2 i pozostawienie samego nginx + php jest znacznie szybsze?

Więcej testów porównawczych

Small 40-byte static file: 1484 r/s via nginx+apache2, 2452 if we talk to apache2 directly. 
Small "Hello world" php script: 458 r/s via ngin+apache2.

Aktualizacja: Wydaje się, że wąskim gardłem jest wydajność MySQL na buforowanych danych. Strona z pojedynczym kodem SQL pokazuje 354 req / s, z 6 kodami SQL - 180 req / s. Jak myślisz, co mogę tu ulepszyć? (Mogę rozwidlić 100-200 Mb dla MySQL)

[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
default-character-set=cp1251
collation-server=cp1251_general_cs

skip-character-set-client-handshake

user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /tmp
skip-external-locking

bind-address        = 127.0.0.1

key_buffer      = 16M
max_allowed_packet  = 8M
thread_stack        = 64K
thread_cache_size   = 16
sort_buffer_size    = 8M
read_buffer_size    = 1M

myisam-recover      = BACKUP
max_connections        = 650
table_cache            = 256
thread_concurrency     = 10

query_cache_limit       = 1M
query_cache_size        = 16M

expire_logs_days    = 10
max_binlog_size         = 100M

[mysqldump]
quick
quote-names
max_allowed_packet  = 8M

[mysql]
[isamchk]
key_buffer      = 8M

!includedir /etc/mysql/conf.d/

Oczywiście możesz wiele spróbować. Najlepszym rozwiązaniem jest gonienie dzienników w poszukiwaniu zapytań, które nie korzystają z indeksów (włącz dzienniki dla nich) i innych niezoptymalizowanych zapytań. Przez lata opracowałem ogromną listę opcji związanych z wydajnością, więc zamieściłem tutaj mały podzbiór dla twojej informacji - mam nadzieję, że to pomaga. Oto kilka ogólnych uwag na temat rzeczy, które możesz wypróbować (jeśli jeszcze tego nie zrobiłeś):

MySQL

• query_cache_type = 1 - buforowane zapytania SQL są włączone. Jeśli ustawione na 2, zapytania są buforowane tylko wtedy, gdy przekazana jest do nich wskazówka SQL_CACHE. Podobnie z typem 1, można wyłączyć pamięć podręczną dla określonego zapytania za pomocą podpowiedzi SQL_NO_CACHE
• key_buffer_size = 128M (domyślnie: 8M) - bufor pamięci dla indeksów tabel MyISAM. Na serwerach dedykowanych staraj się ustawić rozmiar klucza_bufor na co najmniej jedną czwartą, ale nie więcej niż połowę całkowitej ilości pamięci na serwerze
• query_cache_size = 64M (domyślnie: 0) - rozmiar pamięci podręcznej zapytania
• back_log = 100 (domyślnie: 50, max: 65535) - Kolejka oczekujących żądań połączenia. Ma to znaczenie tylko wtedy, gdy jest dużo połączeń w krótkim czasie
• join_buffer_size = 1M (domyślnie: 131072) - bufor używany podczas pełnego skanowania tabeli (bez indeksów)
• table_cache = 2048 (domyślnie: 256) - powinno być max_user_connections pomnożone przez maksymalną liczbę JOINów, które zawiera najcięższe zapytanie SQL. Użyj zmiennej „open_tables” w godzinach szczytu jako przewodnika. Spójrz także na zmienną „open_tables” - powinna być zbliżona do „open_tables”
• query_prealloc_size = 32K (domyślnie: 8K) - trwała pamięć do analizowania i wykonywania instrukcji. Zwiększ, jeśli masz złożone zapytania
• sort_buffer_size = 16M (domyślnie: 2M) - pomaga w sortowaniu (operacje ORDER BY i GROUP BY)
• read_buffer_size = 2M (domyślnie: 128K) - Pomaga przy skanowaniu sekwencyjnym. Zwiększ, jeśli istnieje wiele kolejnych skanów.
• read_rnd_buffer_size = 4M - pomaga tabeli MyISAM przyspieszyć czytanie po sortowaniu
• max_length_for_sort_data - rozmiar wiersza do przechowywania zamiast wskaźnika wiersza w pliku sortowania. Można uniknąć przypadkowych odczytów z tabeli
• key_cache_age_threshold = 3000 (domyślnie: 300) - czas przechowywania bufora kluczy w strefie aktywnej (zanim zostanie zdegradowany do ciepłego)
• key_cache_division_limit = 50 (domyślnie: 100) - włącza bardziej wyrafinowany mechanizm eksmisji pamięci podręcznej (dwa poziomy). Oznacza procent do utrzymania na najniższym poziomie. delay_key_write = ALL - bufor klucza nie jest opróżniany dla tabeli przy każdej aktualizacji indeksu, ale tylko wtedy, gdy tabela jest zamknięta. Przyspiesza to zapisywanie kluczy, ale jeśli korzystasz z tej funkcji, powinieneś dodać automatyczne sprawdzanie wszystkich tabel MyISAM, uruchamiając serwer z opcją --myisam-recovery = BACKUP, FORCE
• memlock = 1 - proces blokady w pamięci (w celu zmniejszenia zamiany wejścia / wyjścia)

Apacz

• zmień metodę spawnowania (na przykład na mpm)
• wyłącz dzienniki, jeśli to możliwe
• AllowOverride None - w miarę możliwości wyłącz .htaccess. Zatrzymuje apache do wyszukiwania plików .htaccess, jeśli nie są one używane, więc zapisuje żądanie wyszukiwania plików
• SendBufferSize - Ustaw na domyślny system operacyjny. W przeciążonych sieciach należy ustawić ten parametr zbliżony do rozmiaru największego pliku, który jest normalnie pobierany
• KeepAlive Off (domyślnie On) - i zainstaluj lingerd, aby poprawnie zamykać połączenia sieciowe i działa szybciej
• DirectoryIndex index.php - Lista plików powinna być jak najkrótsza i absolutna.
• Opcje FollowSymLinks - w celu uproszczenia procesu dostępu do plików w Apache
• Unikaj używania mod_rewrite lub przynajmniej złożonych wyrażeń regularnych
• ServerToken = prod

PHP

• variable_order = "GPCS" (jeśli nie potrzebujesz zmiennych środowiskowych)
• register_globals = Wyłączone - oprócz tego, że stanowi zagrożenie bezpieczeństwa, ma również wpływ na wydajność
• Zachowaj minimalną liczbę ścieżek include_path (unika się dodatkowych wyszukiwań systemu plików)
• display_errors = Wył. - Wyłącz wyświetlanie błędów. Zdecydowanie zalecane dla wszystkich serwerów produkcyjnych (nie wyświetla brzydkich komunikatów o błędach w przypadku problemu).
• magic_quotes_gpc = Wyłącz
• magic_quotes _ * = Wył
• output_buffering = Wł
• Wyłącz rejestrowanie, jeśli to możliwe
• expose_php = Wył
• register_argc_argv = Wył
• always_populate_raw_post_data = Wył
• umieść plik php.ini w miejscu, w którym php będzie go najpierw szukał.
• session.gc_divisor = 1000 lub 10000
• session.save_path = "N; / path" - W przypadku dużych witryn rozważ jego użycie. Dzieli pliki sesji na podkatalogi

Poprawki systemu operacyjnego

• Montuj używane dyski twarde z opcją -o noatime (bez czasu dostępu). Dodaj także tę opcję do pliku / etc / fstab.
• Dostosuj / proc / sys / vm / swappiness (od 0 do 100), aby zobaczyć, co ma najlepsze wyniki
• Użyj dysków RAM - mount --bind -ttmpfs / tmp / tmp

Jeśli wąskim gardłem nie jest procesor, to jego we / wy - sieć lub dysk. Więc ... musisz zobaczyć, jak dużo się dzieje. Nie pomyślałbym, że to sieć (chyba, że ​​używasz łącza półdupleksowego 10 Mb / s, ale warto sprawdzić przełącznik na wypadek, gdyby automatyczne wykrywanie nie działało prawidłowo).

To pozostawia dyskowe operacje we / wy, co może być dużym czynnikiem, szczególnie w przypadku VPS. Użyj sar lub iostat, aby spojrzeć na dyski, a następnie google, jak znaleźć więcej szczegółów, jeśli dysk jest intensywnie używany.

Zajrzałbym do buforowania za pomocą Nginx ( memcached ) lub Varnish .

Przynajmniej powinieneś serwerować pliki statyczne z Nginx, jak powiedział SaveTheRbtz.

Ponieważ serwer nie wydaje się stanowić problemu, być może generator obciążenia jest. Spróbuj uruchomić go na kilku komputerach.

Wydaje mi się, że osiągasz maksymalną liczbę połączeń, które pozwala Apache. Spójrz na konfigurację Apache. Zwiększenie limitu serwera i maksymalnej liczby klientów powinno pomóc, jeśli nie jesteś już związany jakimś innym limitem, takim jak We / Wy lub pamięć. Spójrz na obecne wartości dla modułu mpm_prefork_module lub mpm_worker_module i dostosuj odpowiednio do swoich potrzeb.

ServerLimit 512
MaxClients 512

Czy to obciążenie jest generowane przez narzędzie lub obciążenia w świecie rzeczywistym?

Możesz sprawdzić memcached. Widziałem problemy z wysoką prędkością połączenia powodujące opóźnienia w aplikacji.

Jeśli korzystasz z generatora obciążenia, co otrzymujesz po wejściu na małą stronę statyczną?

Podczas ładowania możesz sprawdzić stos sieciowy pod kątem warunków TIME_WAIT. Być może zapełniasz kolejkę połączeń.

Istnieje około 100 innych powodów i przedmiotów, na które możesz spojrzeć, ale bez dodatkowych informacji, w tej chwili rzucam domysły.

99% procent problemów związanych z czasem pojawi się w bazie danych. Najpierw upewnij się, że Twoje indeksy uderzeń. Jeśli to nie zadziała, zacznij buforować wszystko, co możesz.

Zalecam użycie (jeśli to możliwe) puli połączeń, aby baza danych była połączona z aplikacjami internetowymi (nie trzeba ponownie łączyć się przy każdym żądaniu). To może zrobić ogromną różnicę prędkości.

Spróbuj także przeanalizować wszystkie zapytania za pomocą EXPLAIN (a dlaczego nie profilować swoich zapytań za pomocą SHOW PROFILE?).