Zoptymalizuj Nginx + PHP-FPM, aby uzyskać szybsze czasy odpowiedzi (do obsługi reklam Openx)


Obecnie używam Nginx + PHP-FPM, aby wyświetlać reklamy w OpenX. Obecnie mój czas odpowiedzi jest fatalny, nawet przy niskim obciążeniu. Jednak mój procesor i zasoby pamięci są w porządku, więc nie mogę dowiedzieć się, co to jest wąskie gardło.
Moja obecna konfiguracja dla nginx i php-fpm jest następująca: 
worker_processes 20;

worker_rlimit_nofile 50000;error_log/var/log/nginx/error.log;

pid/var/run/nginx.pid;events {

 worker_connections 15000;

 multi_accept off;

 use epoll;

}http {

 include/etc/nginx/mime.types; access_log/var/log/nginx/access.log; sendfile on;

 tcp_nopush off; keepalive_timeout 0;

 #keepalive_timeout 65;

 tcp_nodelay on; gzip on;

 gzip_disable "MSIE [1-6]\.(?!.*SV1)";

 gzip_comp_level 2;

 gzip_proxied any;

 gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript; include/etc/nginx/conf.d/*.conf;

 include/etc/nginx/sites-enabled/*;

}server {

 listen 80;

 server_name localhost;

 access_log/var/log/nginx/localhost.access.log;# Default location

 location/{

 root/var/www;

 index index.php;

 }## Parse all .php file in the/var/www directory

 location ~ .php$ {

 fastcgi_pass localhost:9000;

 fastcgi_index index.php;

 fastcgi_param SCRIPT_FILENAME/var/www$fastcgi_script_name;

 include fastcgi_params;

 fastcgi_param QUERY_STRING $query_string;

 fastcgi_param REQUEST_METHOD $request_method;

 fastcgi_param CONTENT_TYPE $content_type;

 fastcgi_param CONTENT_LENGTH $content_length;

 fastcgi_ignore_client_abort off;

 }PHP-FPM:

rlimit_files = 50000

max_children = 500

Dodałem tylko parametry PHP-FPM, które zmieniłem na PHP-FPM.
Czy ktoś ma jakieś wskazówki, jak mogę go zoptymalizować, aby móc obsłużyć więcej żądań? W tej chwili widzę straszne czasy reakcji.
2021-03-02 Dodaj komentarz
Udostępnij to

Nie znaleziono powiązanych wyników

    Zaproszony:
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Po pierwsze, jest zbyt wielu pracowników, a limity są zbyt wysokie. Sama maksymalna liczba procesów roboczych dla php-fpm spowolni twój serwer. Usunięcie ograniczeń na serwerze niekoniecznie przyspiesza jego działanie, ale w rzeczywistości może mieć odwrotny skutek.
    • Liczba pracowników: 20 nie ma sensu, jeśli nie masz 20 procesorów/rdzeni maszyny, w rzeczywistości powodujesz negatywny wpływ, ponieważ pracownicy będą mieli nadmierną wymianę zawartości. Jeśli używasz procesora dwurdzeniowego, 2 pracowników powinno wystarczyć.
    • Więzi robocze: Ponownie, samo rzucenie granic w niebo nie rozwiąże twoich problemów. Jeśli twoje wyjście ulimit-n to coś w rodzaju 1024, wtedy twoje działające połączenia powinny być ustawione na 1024 lub mniej (może nawet 768), jest mało prawdopodobne, że będziesz mieć 2 x 1024 jednoczesnych połączeń, szczególnie z czymś takim jak PHP ...
    • Aby uzyskać informacje o lokalizacji katalogu głównego i ustawieniach PHP, zobacz sekcja http:// wiki.nginx.org/Pitfalls http://wiki.nginx.org/Pitfalls, działa najlepiej, jeśli umieścisz dyrektywę root na poziomie serwera {}, a nie na poziomie lokalizacji. Kiedy już to zrobisz, możesz użyć $ document_root $ fastcgi_script_name jako wartość SCRIPT_FILENAME, ponieważ $ document_root automatycznie przeniesie się do bloków układu poniżej.
    • Innymi słowy, możesz bezpośrednio obsługiwać pliki statyczne: 
      location ~* \.(ico|css|js|gif|jpeg|png)$ { expires max; add_header Pragma public; add_header Cache-Control "public, must-revalidate, proxy-revalidate";}
    • Użyj akceleratora PHP, a mianowicie APC (z apc.enabled = 1 w php.ini) lub XCache i zapamiętaj swoje ustawienia php, takie jak memory_limit. Na przykład, jeśli masz system tylko z 2 GB pamięci RAM, nie ma sensu zezwalać na 500 pracowników z limitem 128 MB każdy. Jest to szczególnie ważne, jeśli korzystasz również z innych usług na swoim serwerze.
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Przydałoby się również umieścić: 
    access_log off;

    Przypuszczam, że nie obchodzi Cię generowanie dzienników dla tych żądań.
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Zdecydowanie powinieneś zmniejszyć liczbę pracowników, ponieważ wątpię, czy masz 20 rdzeni/procesorów.
    Zajrzałbym również do twojego serwera bazy danych, istnieje duża szansa, że ​​problem tam jest.
    Ponadto zwiększyłeś
    worker_rlimit_nofile
    do
    50000
    , mam nadzieję, że wiesz, że system operacyjny zwykle ustawia limit na 1024 (domyślnie), możesz spróbować sprawdzić aktualny limit przez wpisując ulimit -n Możesz zwiększyć twardy limit NOFILE (liczba otwartych plików), uruchamiając to polecenie
    ulimit -n 50000
    w init.d lub

    odwiedzając to drugie pytanie na stackoverflow
    https://coderoad.ru/2694004/
    aby dowiedzieć się, jak używać
    limits.conf
    do trwałego ustawiania ograniczeń w całym systemie.
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Naprawdę maksymalizacja wydajności dzięki nginx i php5-fpm to sztuka. Aby to zrobić, musisz naprawdę zrozumieć, jakie treści udostępniasz.
    Na przykład nie widzę żadnego użycia try_files ani żadnego rodzaju buforowania w twojej konfiguracji. Czy wiesz, że nginx ma wbudowaną obsługę memcache? Możesz buforować obrazy i strony html/css, a także strony php. Jeśli zależy Ci głównie na kliknięciach, te kliknięcia będą się liczyć, nawet jeśli wyświetlenia nie są liczone.
    Umieść swoje banery w systemie plików montowania tmpfs, bez access_log lub poziomu globalnego, wyłącz moduły, których nie potrzebujesz w php, użyj najnowszego mysql, użyj InnoDB, aby zmniejszyć blokadę pulpitu, baw się z cysterną InnoDB, aby zmniejszyć zapisy na dysku, zwiększ maksymalną pamięć tabel w mysql, aby zmniejszyć tworzenie plików tymczasowych na dysku, gdy dołączenie jest wymagane przez SQL itp.
    Nginx to tylko część bardzo dużej i złożonej formuły. Nie wspomniałem nawet o parametrze jądra do optymalizacji stosu TCP i wydajności karty sieciowej, wykorzystania wymiany, zużycia pamięci lub kompresji HTML/CSS gzip, którą możesz obsługiwać przez OpenX (jeśli tak).
    I tak, podobnie jak inne wspomniane powyżej, Twoje ustawienia wydają się przesadne i wskazują na brak zrozumienia podstawowych pojęć optymalizacji. Innymi słowy, zatrudnij fachowca :-)
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    czy masz w swojej maszynie 20 procesorów lub rdzeni? może też spróbować zdarzeń domyślnych dla twojego systemu operacyjnego ... może więcej procesów fcgi zamiast większej liczby nginx ... prawdopodobnie zaczynając od 2-4 pracowników nginx ...
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Zdecydowanie zbyt wielu pracowników, jak wspominali ludzie. Osobiście wolę xcache od APC do buforowania kodu operacji php. Powinieneś sprawdzić konfigurację w zmodyfikowanym skrypcie instalacyjnym nginx/php-fpm powłoki centmin auto bash shell

    http://vbtechsupport.com/796
    http://vbtechsupport.com/796/
    /
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Najbardziej efektywnym sposobem na znacznie przyspieszenie systemu serwera jest użycie wirtualnej maszyny Facebook HipHop (HHVM) zamiast PHP (PHP nie powinno być już instalowane).
    HHVM używa procesora nadrzędnego jako „kompilatora Just in Time” i zazwyczaj wykonuje kod PHP 5–10 razy szybciej niż samo PHP, co pozwala dogadać się z mniejszą lub mniejszą liczbą serwerów i znacznie zmniejszyć zużycie energii. Wikipedia użyła HHVM, aby zmniejszyć obciążenie procesora serwera o 5 razy:

    http:// www.golem.de/news/php-Facebook-hhvm-macht-Wikipedia-schneller-1501-111515.html
    http://www.golem.de/news/php-f ... .html
    Można go zainstalować wraz z pakietem Nginx as Linux i bardzo łatwo dołączyć do Nginx, podobnie jak FastCGI, a wkrótce po kilku minutach można go przetestować za pomocą małego pliku PHP „Hello World”:

    https://github.com/facebook/hh ... arted
    https://github.com/facebook/hh ... arted
    Zgodnie z benchmarkami nowy PHP7 PHPNG powinien być tak naprawdę tylko o 30% szybszy.
    dziękuję za poparcie głosowania
    2021-03-02 0 0
    Udostępnij to
    Dlaczego jest złożony? 0 odpowiedzi zostało zwiniętych

    Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się

    Polityka prywatności: https://zweryfikowac.pl/Polityka-prywatnosci.pdf
    Copyright © 2023, All Rights Reserved