szmigieldesign

Jak z tym dyskutować: "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." Albo z tym: "Ale szanuję, mówka handlowca była tu książkowa."

@devopsiarz, korzystałeś kiedyś z wymienionych przeze mnie rozwiązań, w tym z serwera LiteSpeed czy wtyczki o której piszę? Czy piszesz tylko po to, aby komuś dogryźć?

@devopsiarz, wtyczka LiteSpeed Cache dla WordPress to stosunkowo rozbudowane narzędzie, którego funkcje można zamknąć w dwóch grupach: a) szereg narzędzi optymalizacyjnych działających po stronie PHP i funkcji wbudowanych w WordPress (minifikacja, zarządzanie skryptami, obsługa CDN, optymalizacja obrazków, etc.) - te narzędzia działają dla każdej instalacji WordPress, na każdym serwerze. b) interfejs dla cache serwera kompatybilny z licencjonowanymi wersjami LiteSpeed Web Server. Wtyczka może więc działać zarówno w tandemie z wtyczkami generującymi pliki statyczne, jak W3TC czy WP Super Cache, oraz samodzielnie w przypadku serwera LiteSpeed. Zadaniem cache, nawet obsługiwanego przez PHP, jest zmniejszenie zapytań do bazy i opóźnienia przed wysłaniem kodu HTML do przeglądarki klienta - nie jest to więc rozwiązanie pozbawione sensu, nawet jeżeli routing jest oparty o PHP (a trzeba wiedzieć, że zarówno W3TC jak i WP Super Cache są w stanie obsługiwać cache przez .htaccess, czyli z pominięciem PHP). Dla serwerów, które pod obciążeniem generują TTFB na poziomie 0.3 - 0.8 sekundy, uruchomienie cache pozwala na zmniejszenie tego parametru np. do 0.1 lub mniej, nawet przy cache serwowanym przez PHP - po prostu skrypt nie czeka na bazę a PHP obsługuje jedynie prosty routing. @marv, punkty w testach syntetycznych to ostatnie czym powinieneś się kierować jeżeli chodzi o wydajność strony internetowej. Podstawowym parametrem jest czas potrzebny na wyświetlenie kompletnej strony przez przeglądarkę. Nawet taki cache, którego routing jest obsługiwany przez PHP powinien zmniejszyć TTFB - szczególnie w przypadku hostingów współdzielonych, kiedy ruch na serwerze jest znaczący (pamiętaj, że chodzi nie tylko o ruch na Twojej stronie - który może być niewielki - ale także o obciążenie serwera na którym jest Twoja strona). Zobacz mój tekst, pt. "Punkty, punkciki, paranoja", gdzie piszę o wariactwie testów syntetycznych. Kolejna sprawa to skuteczna konfiguracja cache oraz optymalizacji strony (minifikacja, opóźnione ładowanie skryptów, usunięcie niepotrzebnych rzeczy, optymalizacja obrazów, skorzystanie z HTTP2 i precaching, etc. - tego jest całkiem sporo).

Tak jak sam sobie odpowiedziałeś - Wyświetlaj zasoby statyczne, stosując efektywne zasady pamięci podręcznej' dotyczy pamięci podręcznej przeglądarki, albo raczej poinstruowania jej, jak ma traktować materiały pobrane z serwera. WP Super Cache nie dodaje odpowiednich zapisów do .htaccess (o ile mnie pamięć nie myli), robi to W3TC albo LiteSpeed, który niezawodnie polecam do kompletnej optymalizacji stron opartych na WordPress. Myślę, że to dużo lepsze rozwiązanie niż Autoptimize, chociażby ze względu na mnogość opcji, rozbudowane zarządzanie wyjątkami i chyba najlepszą w branży optymalizację obrazów w bibliotece Media. Jeżeli jesteś zainteresowany tematem, na moim blogu przeczytasz więcej o LiteSpeed Cache dla WordPress.

O, dzięki, dobry trop. Obadam

Cześć, poszukuję prostego oprogramowania (np. odpalanego z crona, napisanego w PHP) do cyklicznej synchronizacji maili między skrzynkami. Problem z którym się borykam wygląda tak, że w jednej z firm dla której pracuje zaszła potrzeba posprzątania zamieszania z domenami (dwie spółki korzystające z jednej domeny do maili) i w związku z tym chcemy przenieść skrzynki z domeny A do domeny B. Domena A utrzymywana jest na nazwie razem ze skrzynkami, domena B utrzymywana jest na IBC razem ze skrzynkami. Skrzynki zostały zmigrowane, w nazwie ustawione przekierowanie wiadomości z A do B oraz autoresponder (z informacją o zmianie domeny). Problem jest taki, że serwer IBC odrzuca przekierowaną pocztę i jak twierdzą administratorzy IBC dzieje się to dlatego, że serwer pocztowy nazwy nie obsługuje mechanizmu SPF SRS. Support nazwy twierdzi, że nie obsługuje i nie zanosi się żeby zaczął obsługiwać, co nikogo z tego forum dziwić nie powinno Żeby klienci piszący na maila w domenie A nie otrzymywali zwrotki z serwera B, że ich mail został odrzucony, wpadłem na pomysł aby wyłączyć przekierowanie, zostawić autoresponder i cyklicznie synchronizować wiadomości ze skrzynek w domenie A ze skrzynkami w domenie B (np. co 15 minut). Zakładam, że jakieś 12 miesięcy powinno wystarczyć, aby komunikacja z istniejącymi klientami przeszła na skrzynki w domenie B. Chyba, że ktoś może mnie poratować prostszą strategią to chętnie się przyjrzę.

Główny problem z DDoS ma związek z pierwszą literką, czyli Distributed. Zakładając szczęśliwy scenariusz, że faktycznie atak przeprowadzony jest na wspomniane w komentarzach xmlrpc czy admin-ajax to i tak bardzo dużą liczbę zapytań zamierzasz filtrować przez Apache lub PHP, co negatywnie wpłynie na wydajność. Jeżeli atakowany jest Twój serwis (np. wspomniane pliki w domenie) to Cloudflare może pomóc. Jeżeli atakowany jest serwer przez IP, wtedy najlepiej zadziałają dedykowane narzędzia zainstalowane (bądź nie) po stronie hostingu. W przypadku WordPress, Wordfence przydaje się głównie do raportów przesyłanych na e-mail (co jest przydatne w szczególności kiedy potrzebujesz mieć kontrolę nad wieloma serwisami), do porównywania plików WordPress (motywów i wtyczek) z wersjami znajdującymi się w repozytorium oraz do szybkiego i łatwego wdrożenia pomocnych mechanizmów bezpieczeństwa (ograniczenie prób logowania, zapobieganie wykonywania kodu w /wp-content/uploads/ etc.). Wordfence posiada WAF, ale jest to mechanizm działający z poziomu PHP (czyli nie będący królem wydajności), wymaga wstępnej konfiguracji (która nie jest wykonywana samoczynnie po instalacji) i w wersji darmowej posiada reguły opóźnione o 30 dni względem daty publikacji. Jeżeli hosting nie pomoże, możesz rozważyć subskrypcję usługi od Sucuri. Różnica w stosunku do Wordfence polega na tym, że ruch kierowany jest przez firewall zewnętrzny, a filtry nie są uruchamiane na poziomie Twojego hostingu. Obawiam się jednak, że w przypadku ataków na IP nie filtrowanych skutecznie przez hosting, rezultat będzie podobny jak dotychczas.

Hm, nie jesteś w stanie pobrać nowych wersji wtyczek manualnie ze strony producenta? Czy mechanizm zabezpieczający we wtyczkach efektywnie je wyłączy jeżeli wykryje zmianę domeny?

Hm. Pytanie czy autoryzacja zadziała także dla subdomeny - w takim wypadku mógłbyś uruchomić tymczasową wersję serwisu na subdomenie domeny na którą masz zarejestrowane wtyczki.

Hm, a nie lepiej pobrać kopię, przebudować i wgrać z powrotem? Wtedy downtime wyniesie nie więcej niż godzinę.

Nie można po prostu zrobić przekierowań w htaccess? Jeżeli zmieniasz kategorię (dodajesz lub usuwasz z permalinku) i WordPress sam sobie nie poradzi to jedno przekierowanie z wyrażeniem regularnym w htaccess powinno załatwić sprawę. Z czasem linki w Google zaktualizują się tak jak pisze theqkash.

Zależy od konfiguracji połączenia po stronie Cloudflare. Może być Flexible SSL, Full SSL albo Full SSL Strict. Pierwsze dwa powinny działać nawet jeżeli certyfikat nie jest skonfigurowany poprawnie. Flexible SSL działą tak jak Mion napisał. Zobacz https://support.cloudflare.com/hc/en-us/articles/204144518-SSL-FAQ

No jak to jak, nieuczciwą praktyką rynkową

HTTP/2 nie powinno wykrzaczać layoutu. Zwykle layout się sypie kiedy optymalizujesz jQuery, dlatego w lscache jest osobna opcja wykluczająca jQuery ze wszystkich optymalizacji. Ale faktycznie może być potrzebne głębsze zbadanie tematu i wykluczanie poszczególnych js/css. Pisałeś do HD w tej sprawie? Tak to wygląda u mnie (zał.). Sugeruję wykluczyć też googlesyndication z optymalizacji. lscache pozwala na automatyczną optymalizację obrazków od 1200 kredytów (level 3), ale funkcja ta została dodana niedawno, więc jeśli wcześniej badałeś temat to mogłeś o tym nie wiedzieć.

Dlaczego nie łączysz CSS / JS? Miałeś z tym problemy? Jeżeli jesteś na dhosting, możesz też włączyć HTTP/2 push. Zmieniałeś coś w [6] Tuning względem wartości domyślnych? Ładowanie minifikowanego kodu przed innym może powodować problemy w ładowaniu treści bo zmieniasz kolejność skryptów. Po zmianie ustawień minify / tuning, etc. konieczne jest wyczyszczenie całej pamięci podręcznej. Jedyne błędy jakie widzę u siebie dotyczą Google Ads (403 podczas ładowania zasobów ads) - pomyśl o dodaniu frazy "googleads" do wyjątków js/css. Nie wiem czy korzystasz z optymalizacji obrazów, jeśli nie, zapraszam do mojego krótkiego poradnika - https://szmigiel.design/pl/blog/skuteczna-optymalizacja-grafik-w-wordpress-dzieki-wtyczce-litespeed-cache/