php-fpm i jeden master czy wiele?

[HaPe 242]

Witam, jakie rozwiązanie waszym zdaniem będzie lepsze przy php-fpm z wieloma użytkownikami na serwerze oraz odrębnym pool na każdego użytkownika. Jeden proces master spawnujący procesy czy proces master na każdy pool z osobna?

 

 

http://mattiasgeniar.be/2014/04/09/a-better-way-to-run-php-fpm/

[Pan Kot 1535]

A po co Ci wielu masterów i każdy z jednym poolem? Przecież to będzie tylko niepotrzebnie więcej pamięci zużywać.

 

Oczywiście, że jeden master i wiele pooli.

 

 

 

That inherently means that the APC cache is shared between all PHP-FPM pools. If you only have a single site to serve, that's no issue. If you have a few dozen sites on the same server via PHP-FPM, you should be aware that they all share the same APC cache. The APC cache size should then be big enough to hold the opcode cache of all your sites combined.

 

Jeden z większych bullshitów jakie mogli napisać. Wielkość wszystkich cache'ów APC wszystkich masterów nie może być mniejsza niż wielkość cache'u jednego mastera i wielu pooli. A współużytkowanie cache'u może nieść za sobą tylko i wyłącznie korzyści, np. w przypadku gdy kilka stron używa wordpressa, nie będzie potrzeby powielania w każdym cache'u każdego mastera tych samych współdzielonych instrukcji. Zadaniem mastera FPM jest właśnie takie zarządzanie poolami, żeby robić to jak najbardziej optymalnie, a współdzielony cache może tylko przyspieszyć, a nie spowolnić, działanie każdego poola z osobna.

Edytowano Lipiec 20, 2014 przez Archi (zobacz historię edycji)

[HaPe 242]

Dzięki za wyjaśnienie. Jeszcze w kwestii spawnera procesów php-fpm. Czy powinno się unikać uruchamianie owego spawnera z uprawnieniami root?

[Gość patrys]

Nie, jedynie poole powinny mieć uprawnienia użytkownika

[Pan Kot 1535]

Master działa jako root głównie z tego powodu, żeby mógł spawnować poole odpowiednio dla każdego usera.

 

 

 

 

Tak wygląda najbardziej "odpowiednie" działanie FPM'a.

Edytowano Lipiec 21, 2014 przez Archi (zobacz historię edycji)

[Misiek08 285]

@Archi - z tym APC jesteś pewien? Jak testowałem to miałem wrażenie, że APC dzieli wszystko, więc jak ktoś w APC przechowa np. statystyki, które chciałby mieć tylko dla siebie, to druga strona może mu je "ukraść".

 

Przy hostowaniu tylko własnych stron jest fajnie, ale wtedy i tak trzeba pamiętać, żeby jakieś namespace'y zrobić.

[PapaSmerf 497]

APC jest współdzielone, jeśli workery są uruchamiane z tego samego procesu: źródło.

[HaPe 242]

Czyli najlepszą opcją jest odrębny spawner per user? Z tego co zauważyłem to Progreso.pl coś takiego stosuje.

Edytowano Sierpień 4, 2014 przez HaPe (zobacz historię edycji)

[PapaSmerf 497]

Czy jest sens bawienia się w spawner dla każdego usera? Nie wiem. Zależy od tego czy jesteś do APC przywiązany w jakikolwiek sposób.

 

Mogę Ci powiedzieć ze swojego punktu widzenia (nie administratora): APC dla nowych wersji PHP jest bez sensu (ostatnia stabilna wersja jest z 2012 roku, dla PHP 5.4 dalej (?) wisi jako beta). W PHP 5.5 jest Zend OPCache.

[Pan Kot 1535]

OPCache jest o wiele lepszy od APC, APC to przeżytek.

[dan 2]

Tylko z tego co mi się wydaje to OPCache nie ma cache do danych usera/skryptu, jak APC.

[Gość patrys]

http://pecl.php.net/package/APCu

[dan 2]

http://pecl.php.net/package/APCu

No to właśnie potwierdza, że jakieś tam zalety APC ma :-). Połączenie OPCache i APCu wydaje się być optymalne.

[HaPe 242]

Odnośnie APC jeszcze jedno pytanko, czy APC trzyma cache w /tmp czy w ramie?

[PapaSmerf 497]

Odnośnie APC jeszcze jedno pytanko, czy APC trzyma cache w /tmp czy w ramie?

 

W RAMie.