Skocz do zawartości

Mattpl

Użytkownicy
  • Postów

    17
  • Dołączył

  • Ostatnia wizyta

Treść opublikowana przez Mattpl

  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ę czy nie zabrać 4x ssd 480 i spiąć to w raid 10 na jednej partycji systemu a druga pod bazę. Aktualnie stara maszyna spięta jest w sprzetowy raid1 na dyskach satach i od ok 5 lat nie było z nimi problemów, ilość operacji IO raczej w stronę odczytu. //Edit Tzn. ja jestem za raid10, ale budżetowo przy powyższej konfiguracji jestem już na styku a wrzucenie zamiast 4x 480 to wystrzeli cenę o ok 1k
  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 przy pomocy API z WP (php56) artykuły, podejrzewam że przy każdym request jest wykonywane zapytanie do WP. Zaraz wyłączę sekcję i zobaczę czy coś da.
  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 ServerLimit 800 czasy bez zmian.
  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
  15. Autorski i było już kilku Devów więc każdy zostawił coś od siebie ;/
  16. Witam, rozkładam już ręce bo brakuje mi pomysłów na optymalizacje czasu odpowiedzi, który w ostatnim okresie uległ pogorszeniu. 2-3 tygodnie temu oscylował w granicach 0.8s wcześniej udało się wyciągnąć 0.5s a teraz to 1.2s. Mimo optymalizacji przeróżnych parametrów dla bazy/ apacha php'a ta wartość stoi w miejscu - Mysql - MariaDb 10.1 , przetestowałem kilka konfiguracji, używałem mysqltuner'a etc. - Php w wersji 7.0 - php-fpm + opcache - Apache 2.4 + ngix na revers_proxy + HTTP2 Wszystko aktualne. Wydaje mi się że ten zestaw powinien działać sensownie i dosyć szybko. Serwerownia kylos.pl, 32gb ramu, ssd. Baza spora i tu obstawiałem problem ale dorzuciłem jej ramu do wykorzystania, zwiększyłem cache i niestety nic to nie dało. Zainstalowałem Munina w piątek, niestety to moje pierwsze analizy i jedynie co rzuciło mi się w oczy to spore wykorzystanie pamięci przez cache. WP na tym samym serwerze bez problemów, skrypty ładują się szybko więc wszystkie znaki na niebie przekonują mnie do samego skryptu / bazy. Miałby ktoś chwilę rzucić okiem chociażby na munina i może zauważy wąskie gardło ewentualnie potwierdzić moje przypuszczenia że to strona. Pozdrawiam
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

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