Skocz do zawartości

Mattpl

Użytkownicy
  • Liczba zawartości

    17
  • Rejestracja

  • Ostatnia wizyta

Reputacja

0 Neutral

Informacje osobiste

  • Imię
    Mateusz
  1. Wrzucam do koszyka serwer ale pierw chciałem zaczerpnąć informacji o producencie SuperMicro, wcześniej używałem Fujitsu i HP a SuperMicro aktualnie cenowo wychodzi b.dobrze. Poczytałem i jakościowo jest ok, produkują chyba nawet płyty dla Della? Jakieś opinie z praktyki? Konfiguracja, którą sobie stworzyłem: Xenon E-2226G 3.4G 12M 64Gb Ddr4 Kontroler pod Raid AOC-S3008L-L8I WS2019 E 2x ssd 960gb Zasilanie redundantne Docelowo obsługa softu z bazą pgsql. SSD spięte w raid 1. Pytanie dodatkowe czy baza przy raid 1 to spoko rozwiązanie bo zastanawiam się cz
  2. jakby miał jakiś cache na wyniki dla domeny po 30 minutach zrobiłem retest i wyniki były już ok
  3. aktualnie ta konfiguracja lata apach2.4+nginx
  4. rozważam i nawet to testowałem, ale wykrzaczyła się całkowicie strona przy serwowaniu backendu również przez ngixa i zostawiam to na później jak Dev wyrobi się całkowicie z pracą.
  5. Mion, dzięki za dołączenie do dyskusji, ogólnie jak pisałem problem znaleziony = przy każdym wejściu na stronę odbywało się zapytanie o nowe art. co niepotrzebnie wydłużało czas. // testowałem redisa i opcache -
  6. Jak wyżej pisałem, udało się znaleźć gdzie jest błąd - jest w sekcji z artykułami która jak teraz widać jest pobierana z WP przy każdym zapytaniu. Usunięcie sekcji oczywiście sytuacje zmieniło diametralnie, ttfb = 215ms, teraz task dla programisty aby to poprawić. Bardzo dziękuje Wam za pomoc! // Jeszcze pytanie o https://performance.sucuri.net/ , pokazuje przy każdym teście realne wyniki czy odświeża co jakiś czas? Widże ttfb na poziomie 3s gdzie inne narzędzia pokazują 150-210ms
  7. przy -ttt https://pastebin.com/YDjM6RWX Nie wiem czy o to chodziło, odpalam strace i muszę go przerwać ctrl+c bo danych jest naprawdę dużo, przy każdym wykonaniu // dobra widzę chyba że jednak to nie ten PID dla zapytania z serwisu o TTFB Coś dziwnego znalazłem w Da ustawione dla domeny mam pierwsze php na 7.0 i odpalając plik phpinfo z domeny jest wersja 7.0 ale zatrzymując proces z php5.6 strona pada na pysk z errorem ERR_TOO_MANY_REDIRECTS Ok już chyba wiem co jest Na autorskim skrypcie (php70) jest sekcja z artykułami pobiera prz
  8. ok miałem kilka pidów dla php-fpm7 akurat z tej wersji korzystam przy tym serwisie, odpaliłem i jest dosyć obszernie https://pastebin.com/eY9viNea -- dokładnie, WP na tym serwerze nie ma problemów - TTFB na poziomie 0.184 secs
  9. sprawdzałem i nic, zarówno dla php5.6 i php7 pusty error log
  10. Procesów oczywiście od groma, ale czasy bez zmian ;/ httpd-mpm.conf wleciał conf dla prefork i httpd-default.con wleciała reszta, reload i restart httpd były.
  11. dziennie ok 5-6 tys. UU więc niewiele, szukałem info na temat czy event/prefork/worker i gdzieś przeczytałem że w sumie event jest najbardziej elastyczny dlatego tak też ustawiłem, nie mam problemu z tym aby przejść na prefork. Wartości właśnie zmieniłem, przeładowałem, kolejne pomiary i sytuacja bez zmian dla prefork mam coś takiego w configu za Twoją radą wówczas dla prefork server limit wynosi 15 ale w tym configu przydałoby się zapewne zwiększenie wartości. // Ok, ustawiony prefork, w configu dałem MinSpareServers 350 MaxSpareServers 450
  12. ok, ogólnie jest to Apache z ngixem na reverse proxy - wcześniej był sam apach 2.4 - ta sama sytuacja w obu wypadkach. i config dla Event: StartServers 6 MinSpareThreads 32 MaxSpareThreads 128 ThreadsPerChild 64 ServerLimit 32 MaxRequestWorkers 2048 MaxConnectionsPerChild 10000 Sprawdziłem też z Twojego urla - First Byte zaczyna się od 1.698s także jeszcze gorzej. Tak jak pisałem na przestrzeni jakiś 2-3 tygodni się pogorszyła sprawa
  13. Dzięki za dołączenie do tematu :) Ogólnie według DA zarezerwowane jest dla mysqld 11.47 GB. Mysqltunera oczywiście używałem w dłuższych odstępach czasu i oczywiście zawsze sugerował zwiększenie pewnych parametrów które uprzednio były zmieniane przy jego sugestii. Testuje pingdoomtools z lok. Szwajcaria, Pagespeed ins.. i webpagetest lok. Warszawa i Berlin według top i iotop,
  14. Dzięki za wskazówkę, w takim wypadku zabieram się za kolejne analizy
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.