Skocz do zawartości

devopsiarz

Użytkownicy
  • Ilość treści

    22
  • Rejestracja

  • Ostatnio

Reputacja

2 Neutral

Informacie firmowe

  • Firma/marka
    devopsiarz.pl

Ostatnio na profilu byli

47 wyświetleń profilu
  1. Digital Ocean ma VPSy w datacentrach w USA, nie wspominając o tych popularniejszych dostawcach tego typu usług (Amazon, Google, Microsft)
  2. Nie widzę problemu, głosowanie portfelem działa zawsze. Cisco sprawdza, na ile sobie może pozwolić, a jak będzie wahnięcie finansowe na ich niekorzyść, to zmienią to szybciej, niż ktoś ich zdąży pozwać.
  3. Tak, korzystałem, pierwszy raz w 2015. Ale umówmy się, że jak nie masz zamiaru odnosić się w ogóle do treści merytorycznej mojego posta, to albo na niego nie odpowiadaj, albo nie licz, że będę na poboczne pytania jednozdaniowe odpowiadał. Czyli zamiast zadawać takie pytania, wprost wskaż, gdzie nie mam racji - będzie szybciej i przyjemniej w dyskusji.
  4. Nie działają dla każdej instalacji WordPress i nie na każdym serwerze. Polecam się zapoznać z tym, jak działają czasem wtyczki "pod maską", w tym te co wymieniłeś. One z czegoś korzystają, bo nikt koła na nowo we wtyczce nie wymyśla (np. optymalizacja obrazków). Często same Ci powiedzą, czego Ci brak na serwerze, albo same zaoferują swoje API, za stosowną opłatą powyżej pewnego limitu. Więc nie, nie działają wszędzie i na każdym. Z punktu widzenia użytkownika końcowego lepszy jest cache kompatybilny z popularniejszymi rozwiązaniami. Ale szanuję, mówka handlowca była tu książkowa. Nie, nie może. Tzn. możesz sobie popychać treść między tymi wtyczkami, jak zależy Ci na zwiększeniu latencji, w sytuacji, gdy cache jeszcze nie masz wygenerowanego. Natomiast jak jedna wtyczka działa "dobrze", w sensie robi co powinna, to druga już efektywnie działać nie może. Chyba, że jednak będzie "poprawiać" pierwsza. Zatem kilka wtyczek do statycznych plików to ciekawa idea, ale dziwna i niepotrzebna. Rozwiązanie się sprawdza (jako tako) do pewnej skali, ale jest pozbawione sensu w ogólnym rozrachunku, gdyż: 1) Użycie PHP powoduje zwiększenie zasobów serwera, fakt - bazy nie używamy, jest postęp! 2) Użycie PHP jest problematyczne jeszcze z innego powodu - wciąż jesteś narażony na błędy bezpieczeństwa związane z wtyczkami WP, jak i samym silnikiem PHP - dziwna sytuacja, gdy chcemy serwować pliki statyczne. Podałeś cyfry dla jakiej sytuacji? Jakie obciążenie, strona, routing, przy jakiej treści, jakim protokole konkretnie? Bo wiesz, cyfry bez kontekstu, to tylko cyfry. TTFB jest mocno mylącym parametrem (nie mającym nic wspólnego z tym, co określasz "podstawowym parametrem") i zalecałbym się nim nie przejmować, w ogóle nie mówi nic o wydajności strony jako takiej. Np. mój serwer może błyskawicznie wysłać header i TTFB będzie miał rewelacyjny, a że baza zwróci wyniki za 5 sek to już taka mało znacząca kwestia. 🙂 Skorzystanie z HTTP2, bez kontekstu, tylko na zasadzie "włączmy", może równie dobrze zdegradować wydajność.
  5. To ja bym w to najprostsze rozwiązanie poszedł. Czyli jak skrypt zwraca jakiś kod błędu (jak sam używa polecenia mysql to duża szansa), to odpalać go później znowu - jeśli ten błąd oczywiście wystąpił i jeśli następne odpalenie dopiero problem rozwiązuje. A skrypt definitywnie jakiś nieteges jest.
  6. Oczywiście wszystko zależy od wielkości strony (w tym przypadku m.in. bazy w WP), ilości wtyczek, które "coś robią" itp. Rzeczywiście, jak masz niewielki ruch, parę wpisów na krzyż i nie masz 100 wtyczek, to cache może być zwyczajnie zbędny. Jeżeli bez kombinowania z jakimkolwiek cache, Twojej stronie lepiej i nie narzekasz, to warto przy tym pozostać, zaznaczałem tylko, że wtyczki zazwyczaj robią "pseudo" cache. Działa nawet, ale ten prawdziwy (co daje 100/100 w PageSpeedInsights) wymaga zabawy za kulisami serwera www.
  7. Absolutnie popieram kolegę @Archi w tym co tutaj napisał, tylko dopiszę (jako admin, co ma ponad 12 lat swoje serwery poczty), że należy rozróżnić 2 rodzaje dostarczenia: 1) Dostarczenie do docelowego serwera SMTP (to widać w logach naszego serwera), gdy to zawiedzie zwykle dostajemy zwrotkę. Technologie takie jak greylisting mogą to opóźnić o kilka godzin, bo nasz serwer smtp i docelowy, jeszcze ze sobą "negocjują" - wtedy my nie mamy żadnej informacji - chyba, że mamy dostęp do logów naszego serwera i nasz adresat nie ma żadnej informacji. 2) Dostarczenie do krańcowego użytkownika/adresu e-mail przy założeniu, że docelowy serwer SMTP pocztę odebrał. Tutaj nie wiemy czy krańcowy użytkownik dostał swój e-mail. Mógł jego serwer SMTP go "wziąć", ale mu nie dostarczyć z jakichś powodów (np. skaner antyspamowy, antywirusowy, itp). Z kolei, jeżeli użytkownik dostał już finalnie e-mail do swojej skrzynki, to wciąż tego niekoniecznie będziemy świadomi, jeżeli używa np. zewnętrznego klienta poczty, typu thunderbird, który z automatu blokuje wszystkie linki i obrazki pikselowe i ostrzega wyraźnie, że robi to dla prywatności. Myślę, że interfejs webowy gmail też to w przyszłości zacznie blokować na podobnej zasadzie z automatu. Wniosek: nie ma technologii, która gwarantuje 100% dostarczalność (ba, do czego/kogo - do serwera czy do użytkownika?). Technologię, które "weryfikują" czy użytkownik przeczytał, to już w ogóle loteria i one "działają" w bardzo specyficznych warunkach i "pudłują" z 1/3 maili. Jedynym, 100% pewnym potwierdzeniem dostarczenia e-maila jest e-mail zwrotny od klienta poczty (tzw. potwierdzenie przeczytania - to jest nic innego jak e-mail zwrotny właśnie) lub zwykła odpowiedź od adresata w reakcji na nasz e-mail. Nawet tzw. linki śledzące nie są pewne (te z newsletterów), ponieważ, po tych linkach mogą chodzić automaty skanujące i sprawdzać, czy nie wita ich strona z nagłówkiem application/octet-stream, czyli że nie chce czegoś userowi wysłać.
  8. Końcówka logów to sytuacja, gdy Ty próbujesz się podłączyć do bazy, czy ten skrypt?
  9. Żadna ze znanych mi wtyczek cache, w tym LiteSpeed, mówię o wersjach darmowych, nie robi cache porządnie. Jeśli webserver jest niestandardowy (patrz: nie apache), to robią "biedacache" - wygenerowane pliki statyczne są serwerowane przez... PHP. Nie wiem jak na apache jest, mogę podejrzewać, że też źle. Czyli zamiast serwować bezpośrednio pliki, serwer podaje request do php, a php dopiero "kuma", że ma cache (redis czy coś tym stylu lub właśnie pliki statyczne). Owszem w stosunku do "gołego" WP, te wtyczki przyspieszają działanie strony, ale i tak jest to marnowanie zasobów na wysokim poziomie i zmarnowany potencjał. Jeśli cache ma być porządny, to bez grzebactwa w webserverze się nie obejdzie i/lub współpracy z czymś z rodzaju varnish. Także nie polecam wydawać pieniędzy na te wtyczki, bo to nie jest warte świeczki.
  10. Ja mam tzw. immutable infrastrukture. Tworzę nowy obraz z pełną aktualizacją (w zasadzie to automat po API u Cloud providera) co jakiś czas i jak obraz jest gotowy to w razie potrzeby od razu tworzę nową instancję na bazie tego obrazu (z aktualnymi rzeczami na moment utworzenia obrazu). To ma też taką zaletę, że jak działa "stara" instancja, to na boku mogę stworzyć "nową" i sprawdzić np. kitchen inspec, czy to co wstało, działa prawidłowo. Czysty DevOps.
  11. Uwaga, kandyduję o złotą łopatę! A co do problemu to nic się nie przejmuj, bo masz po prostu podane zwyczajnie parametry z jakimi masz odpalonego demona `php-cgi71`, który obsługuje pliki *.php. Z tego co pamiętam, -d wskazuje parametry konfiguracyjne i w ten sposób jest tutaj ustawiony "sendmail_path" - to parametr, który wpływa na obsługę funkcji "mail()". Według mnie, to co niepokoi, to bez wątpienia parametr "open_basedir" powinno się go używać z głową lub wcale, a tutaj np. widzę "/home/bip" wskazany na luzaka. Pozdrowienia dla konfigurującego z tego miejsca.
  12. Napisałem, że tu nie wiem czy są buforowane. Ponadto, podajesz parametry, które nie robią tego samego i wrzucasz je do jednego worka, nie wiem czy jesteś świadomy co podałeś, ale skonsultuj to z dokumentacją nginx, bo nawet ona explicite mówi jaki jest koszt logów. A to, czy CPU, czy I/O nie zużywasz i jaki to typ operacji, to zależy od webservera, jego konfiguracji i wreszcie konfiguracji systemu (i piszę Ci to m.in. programista, który grzebie w jednym ze znanych webserwerów). To się podziel detalami np. w czym logowałeś (apka), co logowałeś, jaki był faktycznie traffic, jaka była konfiguracja software (OS), hardware. Jako osoba, która zarabia na optymalizacji, chętnie się czegoś nowego nauczę. Bo wiesz, z mojego doświadczenia, z tpsami o którym wspomniałem + tego co znajdziesz w sieci na ten temat, jest właśnie odwrotnie. Ale jestem otwarty na dyskusje. Ja oczywiście się zgadzam z tym stwierdzeniem, nie deprecjonuję logów jako ich samych. Tylko spójrz z czym problem miał OP, a takie scenariusze wielokrotnie miałem do ogarnięcia. Wystarczył zazwyczaj apache/jmeter/siege benchmark z kilku serwerów i serwer zdychał, bo sprawdzał istnienie każdego dziwnego pliku (lub w gorszej sytuacji nie sprawdzał a od razu proksował po regule *.php do php-fpm). Wyłączenie logów w pewnym sensie na szybko pomaga do pewnego stopnia. Bo czasem musimy zdecydować, czy chcemy dostać się do serwera i mieć szansę serwować 1 request na 10 sec, czy chcemy mieć piękne logi, które właśnie, w najlepszym przypadku, są zrzucane do pliku już bo buffor (jak go w ogóle włączono) się zapełnił i przez 5 minut serwer oleje wszystko co chcemy na nim zrobić. Kwestia priorytetów, podałem jedno z możliwych rozwiązań na szybko. Zresztą, nawet OP sam przyznaje, że restart apache na parę dni załatwia problem - to też może potwierdzać moją tezę (pootwierane deskryptory m.in do logów itp) Pozdrawiam,
  13. No tak, jak komuś odpowiem po roku, to złota łopata, a jak sygnalizuję, że niektóre fora automatycznie zamykają stare nieaktywne tematy (co też ma uzasadnienie), to już ktoś oponuje, że "co jeśli". Zdecydujcie się tutaj czego oczekujecie.
  14. Ad.2 -> jesteśmy w internecie, zawsze możesz sypnąć dowodem, chyba znasz jakieś poza "znam większość web serverów"? Ad.4 -> mógłbym się kłócić, bo swoje doświadczenie mam. Moja opinia: przy tym ruchu nie logujemy tego, chyba, że nas load=100, przy 4 vCPU satysfakcjonuje i to, że będziemy wiedzieć, że ktoś odpytuje nasze pliki. Syscalle I/O są kosztowne, a tu nawet nie wiadomo czy on cachuje te logi, czy lecą per request. No ale ja mam doświadczenie za skali rzędu 100 000 tps (tak, requestów na sekundę), więc może przesadzam.
×
×
  • Utwórz nowe...

Ważne informacje

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