Skocz do zawartości
HaPe

PHP-Fpm socket czy tcp/ip

Polecane posty

Witam,

co będzie wydajniejsze przy użyciu nginx+php-fpm, komunikacja po socket czy po tcp/ip?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość patrys

Socket będzie tak minimalnie szybszy, że nie odczujesz różnicy, a jedyne co możesz zobaczyć to błędy w połączeniu do niego :)

Użyj w FPM TCP + dostosuj konfiguracje jądra via sysctl, jakiś tutek będzie w google.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@patrys

A jakie to błędy? ;)

 

Używam na produkcji i developerce już od roku i nawet przy sporym obciążeniu chodzi niewiele, ale zauważalnie szybciej od tcp.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość patrys

Dostaniesz w logach serwera www komunikat o braku możliwości połączenia się z socketem z powodu wykorzystania zasobów.

 

Zależy co nazywasz dużym ruchem, ale mam stos maszyn z nginx+fpm na TCP i działają perfekcyjnie.

Tu proszę prosty bench: http://i.amniels.com/nginx-fast-cgi-performance-unix-socket-vs-tcp-ip

Zauważasz różnice ? :)

 

 

 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Pewnie, że widzę, ale wątpię, że wynikają bezpośrednio z testu, to by nie miało żadnego sensu, musiałby powtórzyć wielokrotnie bo nie chce mi się wierzyć, że unix socket wypada gorzej pod kwestią szybkości w jakimkolwiek teście vs. tcp.

 

Jakiego obciążenia trzeba do wyczerpania zasobów?

 

 

root@archi ~ # cat /proc/sys/fs/file-max
65535
Raczej mało kto hitnie aż tak dużo hostując zwyczajną stronę na php-fpm+nginx, nawet mocno obciążoną. Poza tym limit można zwiększyć via sysctl do naprawdę dużo większych wartości (teoretycznie, w praktyce mi to nigdy potrzebne nie było :D).
Ale zgadzam się, że można dojść do takiego stanu.

 

Edytowano przez Archi (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

A całkiem niedawno miałem taki przypadek, że przy próbie dobicia się ok 600 vhostów do jednego socketa wywalało:

[Thu Aug 15 20:40:36.092313 2013] [:error] [pid 20675:tid 140473616299776] [client ip:64225] FastCGI: fai
led to connect to server "/fcgi/strony.sock": socket file descriptor (4294967295) is larger than FD_SETSIZE (1024),
 you probably need to rebuild Apache with a larger FD_SETSIZE

Przy przerzuceniu vhostów na tcp ruszyło bez najmniejszego problemu, ale już nie było czasu dociekać i bawić się z socketem.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Raczej mało kto hitnie aż tak dużo hostując zwyczajną stronę na php-fpm+nginx, nawet mocno obciążoną. Poza tym limit można zwiększyć via sysctl do naprawdę dużo większych wartości (teoretycznie, w praktyce mi to nigdy potrzebne nie było :D).

Ale zgadzam się, że można dojść do takiego stanu.

 

 

To wtedy i tak po co używać?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Unix socket jest przede wszystkim szybszy, liczby tego aż tak bardzo nie pokazują jak widać, ale ja odczuwam dość znaczną różnicę. Poza tym, że mogą skończyć się limity (które można zwiększyć, a nawet już standardowe są ogromne) nie ma żadnych wad. Dlatego też powinniśmy dyskutować bardziej w stronę "dlaczego nie" zamiast "dlaczego tak" ;).

 

Oba rozwiązania są dobre, a ja po prostu dyskutuję na temat tego które jest lepsze. Jako fanatyk optymalizacji kernela i wszystkich serwerowych usług nie mogę zostawić tak tego tematu :P.

Edytowano przez Archi (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość patrys

@Archi: to prosty test i pokazuje, że socket jest szybszy, sam taki test przeprowadzałem przy budowie serwerów dla jednego projektu i różnice nie były totalnie odczuwalne.

 

TCP ma delikatne opóźnienie, ale przy większej ilości połączeń już go nie widać i naprawdę nie wiem gdzie widzisz tą szybkość.

Parametr podany przez Ciebie to tylko jeden z wielu który musi zostać ustawiony, by serwer mógł przyjąć więcej połączeń.

 

Podsumowując i kończąc, niech każdy użyje czego będzie chciał, różnica jest niewielka z doświadczenia lepiej pracuje się na TCP.

Warto śledzić logi błędów serwera www, bo jest sporo parametrów które odpowiadają za poprawne jego działanie.

 

@Miłosz: Twój błąd to nie problem z socketem, a problem z konfiguracją serwera, bo jak można skompilować soft z limitem do 1024 otwartych plików na produkcyjnej maszynie ? :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@patrys - to nie limit do 1024 plików, tylko limit rozmiaru deskryptora.

 

Ja też używam TCP. Na rzadko używanym poolu jest odczuwalna zmuła przy 1 req po dłuższej nieaktywności, ale przy ogromnym ruchu jak na tą maszynkę nie dostanę błędu mówiącego, że skończył mi się limit połączeń dla socketa (300-400 domyślnie).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Panowie, jeszcze takie pytanie przyszło mi na myśl. Czy php-fpm gadający z webserwerem przez socket podczas zapytań powoduje większe "oranie" po dysku niż w przypadku tcp/ip? Teoretycznie plik socket jest w pewnym sensie abstrakcją.

Zapewne niesensowne byłoby wskazywanie ramdysku jako lokalizacji dla plików socket?

Edytowano przez HaPe (zobacz historię edycji)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość patrys
@patrys - to nie limit do 1024 plików, tylko limit rozmiaru deskryptora.

 

no nie ;)

 

Zapewne niesensowne byłoby wskazywanie ramdysku jako lokalizacji dla plików socket?

 

Jasne, że nie, aczkolwiek dobrym zwyczajem jest by socket był w katalogu tymczasowym, a takie montuje się w miarę możliwości w pamięci.

Wracając do meritum połączenie socket nie wpłynie na obciążenie dysku, tak samo jak nie odczujesz w normalnych warunkach różnicy między socket, a tcp.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Jeśli procesy php będą spawnowane przez fpm w trybie ondemand to czy od strony wydajności będzie to dużo gorsze rozwiązanie niż tryb dynamic, w którym zawsze aktywny jest minimum jeden parser?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Pytanie jaki jest sens, odpowiednio ustawiony dynamic tak dopasuje ilość workerów, żeby było ich wystarczająco, a jednocześnie zbyt dużo z nich się nie nudziło.

 

Ondemand ma taką różnicę, że zawsze masz dodatkowe opóźnienie wynikające z potrzeby zespawnowania nowego workera. I o ile to nie jest problemem dla kilku pooli, o tyle przy kilkunastu lub nawet kilkudziesięciu może to być o wiele bardziej odczuwalne niż dynamic.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Ja zawsze stawiam dynamic i zależnie od stron(y) ustawiam nie tak jak wzór każe, tylko tak jak ja uważam. Np. zdarza mi się, że ustawiam max na 40, min na 3 i spawnuje 5. Dlaczego? Np. hostuję stronę, która niestety ze względu na autoryzację wymaga PHP i jest zawalana ruchem tylko na czas wydawania aktualizacji. W normalnym trybie jest max. 10req/min, ale przy aktualizacjach zdarza się do 150req/s.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×