PHP-Fpm socket czy tcp/ip

[HaPe 242]

Witam,

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

[Pan Kot 1535]

Socket unixowy będzie zawsze szybszy niż tcp/ip.

[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.

[Pan Kot 1535]

@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.

[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 ?

 

 

 

[Pan Kot 1535]

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 ).

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

 

Edytowano Sierpień 18, 2013 przez Archi (zobacz historię edycji)

[Miłosz 2311]

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.

[elcct 159]

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 ).

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

 

 

To wtedy i tak po co używać?

[Pan Kot 1535]

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 .

Edytowano Sierpień 19, 2013 przez Archi (zobacz historię edycji)

[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 ?

[Misiek08 285]

@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).

[HaPe 242]

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 Lipiec 20, 2014 przez HaPe (zobacz historię edycji)

[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.

[HaPe 242]

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?

[Pan Kot 1535]

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.

[Misiek08 285]

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.