Nginx, Wordpress optymalizacja

[FanPL 4]

Hej!

 

Chciałbym się dowiedzieć jakich tricków używacie do optymalizacji (Chodzi o szybsze działanie, a nie zużycie ram/cpu) Nginxa. Wiem, że pewnie na forum było już na ten temat, jednak..

Nie znaleziono rezultatów dla 'nginx optymalizacja'.

Chciałbym również się dowiedzieć jaki plugin dobrze optymalizuje WordPressa, bo obił mi się jakiś o uszy, tylko nie pamiętam jaki.

[Gość Dew]

Polecam: http://www.howtoforg...ze-ubuntu-11.04

 

Pod tym adresem masz konfigurację pod 2 najpopularniejsze wtyczki do Wordpressa.

Edytowano Styczeń 13, 2013 przez Dew (zobacz historię edycji)

[Pan Kot 1535]

Polecam: http://www.howtoforg...ze-ubuntu-11.04

 

Pod tym adresem masz konfigurację pod 2 najpopularniejsze wtyczki do Wordpressa.

Przykro mi, ale za to dostajesz minusa. Nie o to autorowi chodziło.

 

@Topic

Przede wszystkim trzeba zacząć od właściwego dobrania nginxa i php. Z własnego doświadczenia powiem Ci, że php-fpm radzi sobie lepiej od wersji CGI, więc warto się tym bardziej zainteresować.

 

Następnie przechodzimy do podstawowych rzeczy - ilość workerów zarówno nginxa jak i php-fpm powinno się ustawić (maksymalnie) na ilość threadów Twojego procesora. Czyli przykładowo gdy masz 2 rdzenie po 2 thready w każdym to wszystkich threadów (np. w htopie) wyświetla się 4 i właśnie 4 workerów powinieneś ustawić zarówno dla nginxa, jak i php-fpm. W przypadku php-fpm i modelu "dynamic" min childs na 2 i max childs na 4.

 

Potem przechodzimy do samego połączenia nginx'a z php. Nie wiem czemu w wielu poradnikach autorzy proponują połączenie po TCP (127.0.0.1:9000), jest to strasznie słabe rozwiązanie jeśli mówimy tu o tej samej maszynie. O wiele lepszych rozwiązaniem jest użycie unixowego socketa. Całość operacji polega na zamianie:

 

fastcgi_pass 127.0.0.1:9000

na:

fastcgi_pass unix:/var/run/php5-fpm.sock;

(Oczywiście przykładowo)

 

Nie jest to jakiś potężny boost, ale jak mówimy o optymalizacji to trzeba o tym wspomnieć.

Kolejnym krokiem jest użycie jakiegokolwiek skryptu cache'ującego do php. Aktualnie najpopularniejszymi jest APC, xcache oraz eAccelerator. Nie ma większej różnicy i działają bardzo podobnie, toteż wybierz ten, który Ci odpowiada. Ja polecam od siebie APC, ponieważ jest zapakowany już do repo debiana/ubuntu i można go łatwo zainstalować:

apt-get install php-apc

 

Teraz przechodzimy do części właściwej, czyli zaawansowanej optymalizacji.

Zacząć należy od takich podstaw, jak np.

# Basic config
events {
	worker_connections 1024;
	multi_accept on;
	use epoll;
}

 

Jednak to powinno być defaultowe w większości konfiguracji.

Przechodzimy do ciekawszej części:

http {

	# Glowne ustawienia
	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;

	# Podstawowa optymalizacja
	keepalive_timeout 10;
	client_body_timeout 60;
	client_header_timeout 60;
	send_timeout 60;
	types_hash_max_size 2048;

 

Są to wartości przykładowe, ale najważniejsza część dotyczy keepalive. Keepalive potrafi być strasznie pamięciożerny i defaultowa wartość około 65 jest absolutnie niepotrzebna. Wartości 10-20 są o wiele lepsze. Reszta to głównie zabezpieczenia przed loopowaniem, a także wolnymi botami, które mogłyby zaatakować nasz serwer chociażby slowlorisem.

 

Przechodzimy do serca optymalizacji nginxa:

 

		# Zaawansowana optymalizacja
	open_file_cache max=1000 inactive=20s;
	open_file_cache_valid 30s;
	open_file_cache_min_uses 2;
	open_file_cache_errors on;

	# Kompresja Gzip'em
	gzip on;
	gzip_disable "msie6";
	gzip_vary on;
	gzip_proxied any;
	gzip_comp_level 4;
	gzip_buffers 16 8k;
	gzip_http_version 1.1;
	gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
	#gzip_static on;

 

Dzięki cache'owaniu przez nginxa plików obniżamy I/O dysku, a także requesty, przez co strony działają o wiele szybciej, a nginx nie musi wykonywać zapytania do tego samego pliku. Kompresja gzip dodatkowo pomaga w oszczędzaniu łącza, a co za tym idzie przyspiesza ładowanie się stron. Waznym elementem tutaj jest gzip_comp_level - jeśli Twój procesor głównie idluje możesz ustawić wartośc 4-5 (wyższe są już nieopłacalne ale oczywiście możesz poeksperymentować, max to 9), natomiast jeśli jest głównie używany to kompresja rzędu 0-1 będzie właściwa.

 

Tu się kończy najważniejsza część odnośnie nginxa. Reszta jest OS-specific bądź CMS-specific. Do Wordpress'a jest milion wtyczek np. SuperCache (z tego co kojarzę), nie znam go bliżej więc musisz potestować. A co do OS-Specific to fajną opcją jest stworzenie małego RamDisk'u (do 128 mb), skopiowanie na niego plików z HDD i ustawienie vhosta właśnie na ramdisk. Przyspiesza to głównie czas dostępu do plików, a ten jest bardzo ważny (nawet pomimo cache'a nginxa). Musisz jednak pamiętać, że ram po reboocie magicznie zniknie więc w tym wypadku masz dwie opcje - CRON co x minut (polecam 24h), w którym serwer zrzuci dane z ramdisku na HDD bądź w drugą stronę - CRON, który co x minut nadpisze Ramdisk danymi z HDD. Jeśli zamierzasz się bawić z systemem plików to wybierz 1szy sposób, ponieważ nginx defaultowo będzie zapisywał do ramdisku.

 

Tyle krótkiego poradniczka, mam nadzieję że pomogłem.

Edytowano Styczeń 13, 2013 przez Archi (zobacz historię edycji)

[Gość nrm]

Do Wordpress'a jest milion wtyczek np. varnish

Varnish to NIE jest "wtyczka" do Wordpressa ale zakładam, że użyłeś baaardzo szerokiego skrótu myślowego.

[Pan Kot 1535]

Trochę tak, zaraz naprawię swój błąd .

Chodziło mi o to:

http://wordpress.org...wp-super-cache/

 

@fixed.

Edytowano Styczeń 13, 2013 przez Archi (zobacz historię edycji)

[Misiek08 285]

@Archi - może ludzie piszą o zmianie socket na TCP (który niestety tworzy pewien narzut), bo socket przy 150+, a czasami 250+ połączeniach nie wyrabia. "Może" wiem co mówię i "może" ten Twój minus nie jest słuszny, bo pod podanym linkiem w @2 można znaleźć dobrą konfigurację pod WP, a Twoja nie nadaje się nijak pod większy setup. Dlaczego? No przykładowo worker_connections 1024, czyli maks. 256 żądań/s.

 

Może...

[FanPL 4]

Teraz przechodzimy do części właściwej, czyli zaawansowanej optymalizacji.

Zacząć należy od takich podstaw, jak np.

Powiedź mi tylko gdzie znajdę poniższy plik, kawałek bodajże 2-giego mam w konfigu nginxa.

@edit Nie ważne x)

Edytowano Styczeń 13, 2013 przez FanPL (zobacz historię edycji)

[Pan Kot 1535]

worker_connections

Syntax: worker_connections number

 

Default:

 

The worker_connections and worker_processes from the main section allows you to calculate max clients you can handle:

 

max clients = worker_processes * worker_connections

 

Chyba jednak 4x 1024, a nie 1024/4 .

 

Do tego chyba wyraźnie napisałem, że są to przykładowe ustawienia i rzeczy, na które trzeba zwrócić uwagę, a nie jedyna i słuszna konfiguracja. Równie dobrze możesz sobie to zwiększyć.

 

Unix socket nie wyrabia? Ja nie spotkałem się z takim problemem, ale zaraz sprawdzę. Możesz być tego pewny. A jeśli masz jeszcze jakieś zażalenia to o nich napisz, człowiek uczy się całe życie.

 

Do tego nie wiem jakim cudem konfiguracja @2 ma być lepsza od mojej, skoro tam jedynie są podane rewrite'y i ogólna konfiguracja + instalacja apc, a nie optymalizacja pod kątem WP.

Edytowano Styczeń 13, 2013 przez Archi (zobacz historię edycji)

[FanPL 4]

Dzięki wielkie Archi, Dew Tobie też dziękuje za pomoc W miarę zauważalne przyśpieszenie

Edytowano Styczeń 13, 2013 przez FanPL (zobacz historię edycji)

[Pan Kot 1535]

 ab -c 1000 -n 10000 http://127.0.0.1/

Concurrency Level:	  1000
Time taken for tests:   4.999 seconds
Complete requests:	  10000
Failed requests:		0
Write errors:		   0
Non-2xx responses:	  10000
Total transferred:	  3280000 bytes
HTML transferred:	   1620000 bytes
Requests per second:	2000.35 [#/sec] (mean)
Time per request:	   499.912 [ms] (mean)
Time per request:	   0.500 [ms] (mean, across all concurrent requests)
Transfer rate:		  640.74 [Kbytes/sec] received

 

Zrobiłem concurrency 1000, bo więcej po localhoście nie da rady. 10k skończonych żądań, 0 failed i oczywiście w trakcie testu mogłem bez problemu dostać się na stronę zewnętrznie ze swojego komputera. Jeśli kogoś to interesuje to testowanym skryptem był MyBB w wersji 1.6.9. Mam odpalać ten sam test z 9 innych serwerów, żeby udowodnić, że przy concurrency 10k również unix socket działa bardzo dobrze?

 

Czemu na siłę sądzisz, że jedynie Twoja konfiguracja jest słuszna zamiast spytać choćby na priv o takie niuansiki?

 

P.S. Skoro skrypt nie wyrabia docelowych 4x 1024 requestów (ledwo 2k dałem radę z MyBB wyciągnąć) to jakim cudem taka wartość jest za mała? To chyba lepiej dostać errora 503/504 niż katować użytkownika 20x wczytującą się stroną? Zresztą nawet w takim przypadku zdążyłbym ją zwiększyć.

 

 

@Edit

Odpaliłem ten test via 10 screenów z komendą ab, przykład jednego z nich:

Failed requests:        0
Write errors:           0
Non-2xx responses:      20000
Total transferred:      6560000 bytes
HTML transferred:       3240000 bytes
Requests per second:    224.68 [#/sec] (mean)

 

Jak mi nie wierzysz to daj znać na priv i sam zalejesz maszynę requestami .

Edytowano Styczeń 13, 2013 przez Archi (zobacz historię edycji)

[Gość Dew]

Przykro mi, ale za to dostajesz minusa. Nie o to autorowi chodziło.

 

offtopic - mode on

O co Ci chodzi? przecież w tym artykule linkowanym przeze mnie jest to samo co napisałeś w swoim poście... Chyba że ktoś tu ma problem z czytaniem...

Edytowano Styczeń 14, 2013 przez Dew (zobacz historię edycji)

[Pan Kot 1535]

Nie, po prostu sądziłem, że chodzi tu o optymalizację serwera WWW pod kątem WP, a nie doinstalowanie apc i plugina do WP. Można powiedzieć, że różne mieliśmy wizję na daną sytuację, oddaję punkty .

[Misiek08 285]

@Archi - właśnie dlatego napisałem posta, bo zamiast czytać i rozumieć minusujesz. Dobrze, że punkty oddałeś, a wiem o czym piszę. Można oczywiście zmienić wartość dla maksymalnej liczby połączeń dla socketu, jednak dalej mogą występować 50x. Jeżeli potrafisz tylko skopiować mi kawałek dokumentacji o worker_connections to zapraszam do lektury wielu opisów konfiguracji nginx. Każdy request do nginx, który ma związek z PHP to 2 takie połączenia workera, czyli 1024/2. Jak dasz 2 workery to nie ma to wpływu. Piszę o 4 na zapas, bo czytałem też gdzieś teorię, że albo secure_link albo xsendfile przy żadaniu otwiera dodatkowe 2 połączenia dla workera, ale tego nie potwierdzam.

[Pan Kot 1535]

Nie zmienia to faktu, że worker_connections można sobie zwiększyć nawet 10x bez jakichkolwiek większych problemów .

Edytowano Styczeń 14, 2013 przez Archi (zobacz historię edycji)