Serwer www na Raspberry Pi5 z dostępem do internetu cz. 5 | Optymalizacja

Słowem wstępu

W sieci możemy znaleźć wiele wymagających i bardzo rozbudowanych serwisów internetowych, które są niesamowicie szybkie. Korzystanie z ich zasobów jest czystą przyjemnością, Możemy znaleźć też wiele stron, które są proste, nie wiele na nich treści, a działają bardzo wolno. Mamy wrażenie, że wczytują się w nieskończoność, korzystanie z nich jest mówiąc delikatnie, mocno frustrujące.

Powiesz, że to głównie zależy od szybkości serwera i będziesz miał poniekąd rację. Ktoś inny mógłby powiedzieć, że ważna jest też przepustowość łącza, ewentualnie ilość osób odwiedzających naszą stronę internetową (czy też strony) – tworzące się kolejki i rosnące obciążenie serwera – i on także będzie miał rację.

Przyglądając się bliżej takim stronom, będziesz mógł jednak stwierdzić, że wiele z nich jest hostowana dokładnie u tego samego usługodawcy (stoją na tych samych serwerach). Działają one dokładnie na tych samych łączach internetowych. Strony bardziej popularne, z większą liczbą osób je odwiedzających, są jednak często szybsze niż strony, których praktycznie nikt nie odwiedza. O co tu więc chodzi ?

Oczywiście przyczyn dla których strona może działać wolno (czy też bardzo wolno) jest wiele i ciężko jest tu je wszystkie wymienić Do najczęstszych należą (jak podpowiada mi wieloletnie doświadczenie), brak optymalizacji zarówno samej strony internetowej jak i serwera na jakim ona jest hostowana.

Jeżeli korzystasz z typowego konta hostingowego to, z optymalizacją serwera pod własne strony nie za wiele zrobisz. Najzwyczajniej nie masz do niego fizycznego dostępu. Konfiguracja oraz optymalizacja takich serwerów jest najczęściej zrobiona przez pracowników danej firmy hostingowej, ale pod kontem ogólnego zastosowania, czyli w taki sposób, aby większość stron jakie uruchamiają na nich ich użytkownicy, mogła funkcjonować bez jakichś większych problemów (niekoniecznie jednak optymalnie).

W razie jednak pojawienia się problemu np. z wolnym działaniem jakiejś strony, to aby móc zaoferować wyższą i zarazem droższą ofertę hostingową, o trochę lepszych parametrach (większa pojemność dysku twardego, większe limity na wykorzystanie procesora, trochę większą pamięć, ewentualnie ofertę zoptymalizowaną pod dany skrypt np. serwer wordpress lub prestashop, dostęp do serwera cachującego jak memcache, czy redis itp.).

Optymalizacja strony internetowej

W większości przypadków, sama optymalizacja strony internetowej nie jest trudna (a przynajmniej jej podstawy), jeśli zadbasz o kilka rzeczy i będziesz przestrzegał kilku zasad.

W dzisiejszych czasach rzadko buduje się własny serwis internetowy niejako od zera, a wykorzystuje się gotowe skrypty do tego celu, w zależności od przeznaczenia strony. Najczęściej korzysta się z gotowych skryptów takich jak WordPress, Drupal, Joomla, PrestaShop, MediaWiki, SMF Forum, PHPbb itp. jest tego naprawdę sporo.

Zaletą takiego rozwiązana są mniejsze koszty budowy strony, krótszy czas potrzebny do uruchomienia takiej strony, jak i pewne umiejętności programistyczne jakie musiałbyś posiadać pisząc taką stronę od zera (tutaj ich brak).

Skrypty te są najczęściej bardzo dobrze zoptymalizowane zarówno pod względem wydajności jak i tzw. seo (czyli mówiąc bardzo ogólnikowo, są przyjazne też dla wyszukiwarek internetowych). Stąd też ty, jako właściciel strony powinieneś zadbać przede wszystkim o jej dobrą kondycję, czyli

dobór odpowiedniego skryptu – nie tylko pod względem jego funkcjonalności ale także wydajności. Instalowanie różnych egzotycznych (mało znanych i niepopularnych) skryptów, nie jest dobrym pomysłem. Jeśli brak ci umiejętności, co do ich ewentualnej naprawy, a może się zdarzyć, że będą spore problemy z ich poprawnym funkcjonowaniem, nie powinieneś tego robić.

odpowiednią optymalizację zdjęć i video przed wrzuceniem ich na stronę – zmniejszenie ich rozdzielczości do akceptowalnej wartości, zastosowanie odpowiedniego formatu dla zdjęcia lub filmu, jego kompresji. Zdjęcie takie powinno mieć nie więcej niż 1mb. Akceptowalne wartości jednak powinny się wahać w granicach maks. 100kb-400kb. Co do filmów, to warto rozważyć umieszczanie ich najpierw w serwisie youtube i dopiero potem, hotlinkowania ich na stronę.

Nie instalowanie nadmiaru wtyczek/pluginów – wiele skryptów umożliwia zainstalowanie wszelkiego rodzaju dodatków, rozszerzających funkcje danego skryptu. Ich nadmiar jednak, jest skutecznym sposobem do zabicia strony internetowej. Uważaj także na źle napisane pluginy.

Wycięcie toksycznych botów i ip – nadmiar różnego typu botów odwiedzających Twoją stronę internetową (są to różnego rodzaju boty serwisów udostępniających jakieś statystyki i zbierające do nich dane jak np. ahrefs, boty spamujące, reklamowe, marketingowe itp.), jest kolejnym czynnikiem dzięki któremu może ona nie działać tak szybko jak byś tego po niej oczekiwał i zarazem będzie obciążać nadmiernie nasz serwer. To czego będziesz chciał się pozbyć, zależy oczywiście od ciebie. Jeśli nie jest to jakiś nietypowy serwis, to możesz wzorować się na moim podejściu do tego tematu.

Blokujemy wszystko, a następnie udostępniamy to, co jest nam potrzebne, czyli boty Google, boty przeglądarek internetowych, ewentualnie jakiegoś portalu dla naszych statystyk. Nie blokujemy tu oczywiście zwykłych użytkowników. Należy tu nadmienić, aby takie blokady robić w .htaccess, a nie np. w pliku robots.txt, którego ustalone przez nas zasady, spora część botów najzwyczajniej ignoruje.

Dodaj więc do pliku .htaccess poniższe reguły

#Dopuszczenie do strony wybranych botów internetowych i blokada reszty

SetEnvIfNoCase User-Agent .*google.* search_robot
SetEnvIfNoCase User-Agent .*yahoo.* search_robot
SetEnvIfNoCase User-Agent .*BingBot.* search_robot
SetEnvIfNoCase User-Agent .*Mozilla.* search_robot
 
Order Deny,Allow
Deny from All
Allow from env=search_robot

Jak można się domyślić, powyższa reguła dopuszcza jedynie boty Google oraz wszystkie znane przeglądarki (także wszystkie, które są oparte na silniku chromium). Gdybyś chciał jednak dopuścić jakieś inne boty, będziesz musiał dodać kolejne reguły do listy, na wzór istniejących. Nazwy interesujących ciebie botów możesz znaleźć w logach systemowych albo w internecie.

Co do samych adresów ip. to najlepiej blokować ich całe segmenty, całe bloki adresów ip, skąd idzie największy spam i próby ataków na stronę.

Uwaga: Blokowanie dostępu poprzez adres ip. dla stron z włączonym proxy (Cloudflare, inne serwery cdn itp.) – włączona pomarańczowa chmurka w rekordach dns Cloudflare – , jest bez sensu.

Cloudflare, czy też inne serwery cdn są serwerami pośredniczącymi, więc ruch będzie blokowany jedynie pomiędzy naszym serwerem, a serwerem proxy (serwerem pośredniczącym). Ruch pomiędzy serwerem proxy, a komputerem klienta nie będzie blokowany.

Z tego powodu taka blokada miała by sens, ale w przypadku globalnego blokowania ip, dla całego serwera, a nie tylko poszczególnych stron internetowych.

Jako, że po za rekordami dns stron internetowych, innych rekordów proxy nie obejmuje, chronione będą wtedy połączenia ftp, poczta, ssh itp.

Powinniśmy blokować całe kraje, takie jak Indie, Rosja, Pakistan, różne kraje afrykańskie i ameryki płd. Jeżeli nie zależy nam na odwiedzinach z tych krajów i nie nastawiamy się np. na klientów stamtąd (prowadząc np. sklep internetowy) możemy je spokojnie zablokować.

Dodając kolejne bloki ip do .htaccess, wcześniej, czy później napotkasz pewien problem. Lista zrobi się dość pokaźna i ciężko będzie w niej cokolwiek znaleźć. Kolejnym problemem może okazać się aktualność takiej listy i ciągłe dbanie o to, aby była ona aktualna. Także obciążenie serwera może wzrosnąć znacznie, który przecież z każdym wywołaniem strony internetowej będzie musiał to wszystko sprawdzić. Czy można prościej? okazuje się, że tak. Nie w każdym przypadku taka blokada się sprawdzi, ale w 99/100 tak.

Najpierw jednak zainstaluj odpowiedni moduł do swojego serwera Apache, geoip. To o geoip oparta jest poniższa reguła w .htaccess, więc jest on wymagany. Wydaj w konsoli swojego serwera poniższe polecenia

# sudo apt install libapache2-mod-geoip
# sudo a2enmod geoip
# sudo systemctl restart apache2

Kiedy moduł geoip jest już zainstalowany, włączony i serwer Apache jest przeładowany

dodaj do .htaccess swojej strony poniższe reguły

RewriteEngine On
RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^[RO|RU|UA|IL|IN|IR|NG|PK]$ [NC]
RewriteRule (.*) - [F]

Powyższa reguła blokuje dostęp do naszej strony krajom takim jak Rumunia, Rosja, Ukraina, Izrael, Indie, Iran, Nigeria, Pakistan, czyli krajom skąd według mnie idzie najwięcej prób ataków na strony oraz krąży największa ilość podejrzanych botów. Boty te często podszywają się pod popularne usługi np. Google, mają jednak inne ip, więc warto wyciąć je dodatkowo właśnie po ip :]

Wspomniałem, że nie na każdej stronie taki sposób blokady się sprawdzi. Przykładem niech będzie blokada takich krajów jak Stany zjednoczone, czy Irlandia. Gdybyś z jakiegoś powodu musiał te kraje zablokować na swojej stronie (dostęp użytkowników z tych krajów do strony), to licz się z tym, że zablokujesz także boty Google (boty indeksujące, statystyk itp.) i inne popularne usługi, których firmy w tych krajach mają swoje główne siedziby. Warto zwrócić na to uwagę i o tym pamiętać.

Obejściem tego problemu jest zablokowanie wszystkich ip krajów nas interesujących, a potem odblokowanie poszczególnych ip, które nie chcemy, aby były blokowane.

RO|RU|UA|IL|IN|IR|NG|PK w powyższej regule to identyfikatory blokowanych krajów. Dostosuj je do własnych preferencji. Poniżej znajdziesz listę poszczególnych krajów wraz z ich kodami/identyfikatorami

AD | Andora
AE | Zjednoczone Emiraty Arabskie
AF | Afganistan
AG | Antigua i Barbuda
AI | Anguilla
AL | Albania
AM | Armenia
AO | Angola
AP | Region Azji i Pacyfiku
AQ | Antarktyda
AR | Argentyna
AS | Samoa Amerykańskie
AT | Austria
AU | Australia
AW | Aruba
AX | Wyspy Alandzkie
AZ | Azerbejdżan

BA | Bośnia i Hercegowina
BB | Barbados
BD | Bangladesz
BE | Belgia
BF | Burkina Faso
BG | Bułgaria
BH | Bahrajn
BI | Burundi
BJ | Benin
BL | Saint Bartelemey
BM | Bermudy
BN | Brunei Darussalam
BO | Boliwia
BQ | Bonaire | Święty Eustatius i Saba
BR | Brazylia
BS | Bahamy
BT | Bhutan
BV | Wyspa Bouveta
BW | Botswana
BY | Białoruś
BZ | Belize

CA | Kanada
CC | Wyspy Kokosowe (Keelinga)
CD | Kongo | Republika Demokratyczna
CF | Republika Środkowoafrykańska
CG | Kongo
CH | Szwajcaria
CI | Wybrzeże Kości Słoniowej
CK | Wyspy Cooka
CL | Chile
CM | Kamerun
CN | Chiny
CO | Kolumbia
CR | Kostaryka
CU | Kuba
CV | Wyspy Zielonego Przylądka
CW | Curacao
CX | Wyspa Bożego Narodzenia
CY | Cypr
CZ | Republika Czeska

DE | Niemcy
DJ | Dżibuti
DK | Dania
DM | Dominika
DO | Republika Dominikany
DZ | Algieria

EC | Ekwador
EE | Estonia
EG | Egipt
EH | Sahara Zachodnia
ER | Erytrea
ES | Hiszpania
ET | Etiopia
EU | Europa

FI | Finlandia
FJ | Fidżi
FK | Falklandy (Malwiny)
FM | Mikronezja (Sfederowane Stany Mikronezji)
FO | Wyspy Owcze
FR | Francja

GA | Gabon
GB | Zjednoczone Królestwo (United Kingdom)
GD | Grenada
GE | Gruzja
GF | Gujana Francuska
GG | Guernsey
GH | Ghana
GI | Gibraltar
GL | Grenlandia
GM | Gambia
GN | Gwinea
GP | Gwadelupa
GQ | Gwinea Równikowa
GR | Grecja
GS | Georgia Południowa i Sandwich Południowy
GT | Gwatemala
GU | Guam
GW | Gwinea Bissau
GY | Gujana

HK | Hongkong
HM | Wyspy Heard i Wyspy McDonalda
HN | Honduras
HR | Chorwacja
HT | Haiti
HU | Węgry

ID | Indonezja
IE | Irlandia
IL | Izrael
IM | Wyspa Man
IN | Indie
IO | Brytyjskie Terytorium Oceanu Indyjskiego
IQ | Irak
IR | Iran | Islamska Republika
IS | Islandia
IT | Włochy

JE | Golf
JM | Jamajka
JO | Jordania
JP | Japonia

KE | Kenia
KG | Kirgistan
KH | Kambodża
KI | Kiribati
KM | Komory
KN | Saint Kitts i Nevis
KP | Korea | Demokratyczna Republika Ludowa
KR | Korea | Republika
KW | Kuwejt
KY | Kajmany
KZ | Kazachstan

LA | Laotańska Republika Ludowo-Demokratyczna
LB | Liban
LC | Święta Lucia
LI | Liechtenstein
LK | Sri Lanka
LR | Liberia
LS | Lesotho
LT | Litwa
LU | Luksemburg
LV | Łotwa
LY | Libijska Arabska Dżamahirija

MA | Maroko
MC | Monako
MD | Mołdawia (Republika Mołdawii)
ME | Czarnogóra
MF | Święty Marcin
MG | Madagaskar
MH | Wyspy Marshalla
MK | Macedonia
ML | Mali
MM | Myanmar
MN | Mongolia
MO | Makao
MP | Mariany Północne
MQ | Martynika
MR | Mauretania
MS | Montserrat
MT | Malta
MU | Mauritius
MV | Malediwy
MW | Malawi
MX | Meksyk
MY | Malezja
MZ | Mozambik

NA | Namibia
NC | Nowa Kaledonia
NE | Niger
NF | Wyspa Norfolk
NG | Nigeria
NI | Nikaragua
NL | Holandia
NO | Norwegia
NP | Nepal
NR | Nauru
NU | Niue
NZ | Nowa Zelandia

OM | Oman

PA | Panama
PE | Peru
PF | Polinezja Francuska
PG | Papua Nowa Gwinea
PH | Filipiny
PK | Pakistan
PL | Polska
PM | Saint-Pierre i Miquelon
PN | Pitcairn
PR | Portoryko
PS | terytorium palestyńskie
PT | Portugalia
PW | Palau
PY | Paragwaj

QA | Katar

RE | Zjazd
RO | Rumunia
RS | Serbia
RU | Federacja Rosyjska
RW | Rwanda

SA | Arabia Saudyjska
SB | Wyspy Salomona
SC | Seszele
SD | Sudan
SE | Szwecja
SG | Singapur
SH | Święta Helena
SI | Słowenia
SJ | Svalbard i Jan Mayen
SK | Słowacja
SL | Sierra Leone
SM | San Marino
SN | Senegal
SO | Somali
SR | Surinam
SS | Południowy Sudan
ST | Wyspy Świętego Tomasza i Książęca
SV | Salwador
SX | Sint Maarten
SY | Republika Syryjsko-Arabska
SZ | Suazi

TC | Wyspy Turks i Caicos
TD | Czad
TF | Francuskie Terytoria Południowe
TG | Togo (Republika Togijska)
TH | Tajlandia
TJ | Tadżykistan
TK | Tokelau
TL | Timor Wschodni
TM | Turkmenia
TN | Tunezja
TO | Tonga
TR | Turcja
TT | Trynidad i Tobago
TV | Tuvalu
TW | Tajwan
TZ | Tanzania | Zjednoczona Republika

UA | Ukraina
UG | Uganda
UM | Dalekie Wyspy Mniejsze Stanów Zjednoczonych
US | Stany Zjednoczone
UY | Urugwaj
UZ | Uzbekistan

VA | Stolica Apostolska (Państwo Watykańskie)
VC | Saint Vincent i Grenadyny
VE | Wenezuela
VG | Brytyjskie Wyspy Dziewicze
VI | Wyspy Dziewicze Stanów Zjednoczonych
VN | Wietnam
VU | Vanuatu

WF | Wallis i Futuna
WS | Samoa

YE | Jemen
YT | Majotta

ZA | Afryka Południowa
ZM | Zambia
ZW | Zimbabwe

Nie wklejamy treści na zasadzie kopiuj wklej – szczególnie tyczy się to kopiowania treści z innych stron internetowych. Treści takie będą zawierały zdefiniowane klasy formatowania dla stron, z których treść jest kopiowana. Mogą one też zawierać linki do obcych stron i inne elementy, których byśmy nie chcieli na swojej stronie, a które mogą też wpływać na obniżenie wydajności naszej strony.

Jeśli musimy już coś skopiować, aby zamieścić na stronie w formie np. cytatu, to wklejmy taką treść najpierw do np. notatnika i dopiero stamtąd na naszą stronę. Taka prosta operacja pozwoli na pozbycie się różnych śmieci z kopiowanej treści. Śmieci te są najczęściej ukryte przed naszym wzrokiem. Formatowanie, dla tak oczyszczonego tekstu, ustawiamy już na naszej stronie (wszelkie boldy, kursywy itp.).

Te proste zasady, pozwolą utrzymać ci na stronie porządek i pozwolą uniknąć wielu błędów wpływających na pogorszenie wydajności twojej strony internetowej. Jest to taka podstawa, dzięki której komfort korzystania z Twojej strony internetowej znacznie się poprawi. Prawdziwa magia zaczyna się jednak przy wykorzystaniu tzw. cache.

Cachowanie treści stron internetowych

Dzisiejsze dynamicznie ładowane strony internetowe, działają pokrótce na takiej zasadzie, że jeśli idą zapytania do serwera www od użytkowników, to serwer odpowiada przesłaniem na przeglądarkę użytkownika konkretnej strony internetowej (lub błędu np. 404, jeśli z jakiegoś powodu nie może przesłać strony).

Mówiąc bardziej szczegółowo to, uruchamiane jest wtedy wiele mechanizmów takich jak m. inn. interpreter phpa lub innego języka. Interpreter tłumaczy kod strony na znaczniki html, w tym czasie idą także zapytania do bazy danych, z której pobierane są odpowiednie treści. Całość wysyłana jest też do przeglądarki. To wszystko zajmuje sporo czasu i zasobów serwera. Wymyślono więc tzw. cache, dzięki któremu całość operacji może być krótsza i mniej obciążająca dla serwera.

Zasada działania takiego cache jest dość prosta. Do cache zrzucane są gotowe fragmenty strony i stamtąd wysyłane są one do przeglądarki użytkownika. Gdzie tu oszczędność ? Elementy cache trzymane są tam do czasu, aż coś na stronie się nie zmieni. Jeżeli coś ulegnie zmianie, cache jest aktualizowany.

Jak wspomniałem do przeglądarki użytkownika przesyłana jest strona z tzw. cache, więc serwer nie musi za każdym razem uruchamiać interpretera php i łączyć się z bazą danych. Skraca to czas przesłania takiej strony, jak i zmniejsza obciążenie samego serwera.

Sposobów cachowania jest wiele ,jednak możemy podzielić go na trzy główne kategorie, rozpatrując sposób jego implementacji. Przy czym najlepszy efekt można uzyskać, łącząc ze sobą poszczególne sposoby.

Cache po stronie przeglądarki użytkownika – Wykorzystując tzw. nagłówki serwera i expires lub max-age, jesteśmy w stanie sprawić, aby strona była cachowana na przeglądarce użytkownika. Dzięki takiemu podejściu, kolejne jej uruchomienia będą dużo szybsze i jednocześnie mniej obciążające nasz serwer.

Serwer proxy i odwrotny serwer proxy – Żeby przyspieszyć działanie naszej strony możemy uruchomić dwa serwery www, z czego jeden będzie pracował w trybie tzw. odwrotnego proxy. Często spotykaną konfiguracją jest np. serwer Nginx -> Apache, gdzie serwer Nginx pracuje właśnie w trybie odwrotnego proxy na tzw. backendzie, natomiast Apache działa na frontendzie, jako normalny serwer www. Innym sposobem jest uruchomienie i konfiguracja oprogramowania Varnish. Możliwości jest wiele.

Konfiguracje takie działają z powodzeniem na wielu serwerach ale mają one kilka wad. Same w sobie wymagają większych zasobów sprzętowych, nie są proste w konfiguracji oraz często są problematyczne w samym ich wdrożeniu, co raczej dyskwalifikuje je w naszym zastosowaniu.

Innym podejściem są tzw. serwery CDN, są to zewnętrzne serwery proxy, których działanie opiera się na usługach zewnętrznych, poza naszym serwerem. Ściślej rzecz biorąc między naszym serwerem, a komputerem użytkownika.

nasz serwer -> serwer cdn -> komputer użytkownika z przeglądarką internetową.

Korzystanie z tego rozwiązania ma wiele zalet. Poczynając od względów bezpieczeństwa, gdyż nasz serwer ukryty jest niejako za takim serwerem cdn, poprzez skrócenie drogi od przeglądarki użytkownika, do serwerów cdn na jakim strony mogą być cachowane (ważne w przypadku zagranicznych użytkowników naszej strony) i tym samym szybszego ładowania się strony.

Takie serwery często oferują wiele innych usług, jak łagodzenie ataków ddos, czy innych funkcjonalności mających wpływ na szybkość naszej strony. Liderem w tej branży jest CloudFlare i to na jego podstawie omówimy dokładniej ten rodzaj cache.

Redis, MemCache i APCu – Cache działający po stronie naszego serwera (może on być także wykorzystany zdalnie poprzez sieć, ale wtedy musimy się liczyć z dodatkowymi opóźnieniami).

Wykorzystuje on pamięć ram naszego serwera jako magazyn danych cache. Pamięć ta, jest dużo szybsza niż dysk twardy, więc i strony pobierane są szybciej niż w przypadku pobierania ich z dysku twardego.

Minusem takiego rozwiązania może być mniejsza trwałość takiego cache. Restart serwera spowoduje usunięcie wszelkich danych z pamięci i o ile nie zostaną one wcześniej zapisane na dysku twardym, stracimy je bezpowrotnie.

Expires, Max-Age itp.

Cache ustawiany najczęściej za pomocą pliku .htaccess naszej strony internetowej lub w pliku konfiguracyjnym strony/serwera w przypadku serwera Ngnix. Gotowe reguły można znaleźć bez problemu w internecie, więc nie będę tego ponownie opisywał.

Nadmienię tylko, że występują gotowe pluginy, dzięki którym możemy takie cachowanie włączyć dla naszej strony (bez naszej fizycznej ingerencji w plik .htaccess). Upraszcza i przyspiesza nam to cały proces, Przykładem takiego pluginu jest chociażby W3TC dla wordpressa..

Cloudflare serwer cdn i nie tylko

Jak już wspomniałem CloudFlare, jest to jeden z licznych serwerów cdn dostępnych na rynku. Dla nas o tyle ważny, że wiele przydatnych funkcji udostępnia nam zupełnie za darmo. Udostępnia nam on około 20tu serwerów cdn rozsianych po całym świecie w wersji bezpłatnej, i pond 100 w wersji płatnej.

Ich użycie znacząco w wielu przypadkach może wpłynąć na szybkość ładowania się naszej strony, głównie dla osób łączących się zza granicy. Inne z jego przydatnych funkcji to, chociażby ochrona przed atakami ddos, możliwość wygenerowania bezpłatnych certyfikatów ssl, funkcje dodatkowo przyspieszające naszą stronę, których z jakiegoś powodu nie chcemy lub nie możemy uruchomić na naszym serwerze bezpośrednio. Są to m. inn. brotli, http/3, własny serwer dns i wiele więcej.

Dokładny opis opcji, jego konfigurację oraz coś więcej o samym CloudFlare opiszę w innym artykule na jego temat.

Redis, Memcache i APCu

Z całej trójki to Redis wiedzie obecnie prym i jest moim faworytem, kolejnym jest Memcache i następnie APCu. Często jednak bywa, że nie zawsze możemy użyć Redisa, ze względu na brak wsparcia dla niego dla danego skryptu strony (np. PrestaShop), czasem nie możemy użyć też Memcache i jesteśmy skazani na APCu.

APCu, co by tu nie mówić jest najstarszym rozwiązaniem z prezentowanej trójki, więc i jego zastosowanie w wielu przypadkach może być mniej efektywne niż konkurencji. Wielkim plusem jest natomiast jego łatwość wdrożenia.

Z tego też powodu dobrze jest mieć zainstalowane na naszym serwerze wszystkie trzy (Redis, Memcache i APCu). Tym bardziej, że w żaden sposób one ze sobą nie kolidują.

Wydaj w konsoli swojego serwera polecenie

$ sudo apt install redis-server php8.3-redis memcached php8.3-memcached, php-apcu

gdzie x jest nr. wersji php dla której instalujesz apcu. Jeżeli będziesz instalował cache też dla innych wersji php, zmień odpowiednio wpis w powyższym poleceniu instalacyjnym.

redis-server oraz memcached to oczywiście serwery redis i memcached. php-redis, php-memcached oraz php-apcu to rozszerzenia dla php.

APCu

Użycie jego sprowadza się zazwyczaj do włączenia odpowiedniej opcji, na stronie w panelu administracyjnym, lub dokonanie odpowiedniego wpisu, do pliku konfiguracyjnego strony. Powinno być to opisane w instrukcji dla skryptu na jakim ona stoi. O ile oczywiście dany skrypt wspiera APCu. Dla APCu nie potrzebna jest żadna dodatkowa konfiguracja.

Memcached

Podobnie jak w powyższym przypadku użycie jego sprowadza się zazwyczaj do włączenia odpowiedniej opcji na stronie panelu administracyjnego lub dokonanie odpowiedniego wpisu w pliku konfiguracyjnym strony. Powinno być to także opisane w instrukcji dla skryptu na jakim ona stoi. O ile oczywiście dany skrypt wspiera Memcached.

Memcached jest konfigurowalny. Jego standardowa konfiguracja jednak, jest właściwa dla naszych zastosowań, możemy jednak podnieść bufor z 64mb do 256mb.

Na początek uwaga. Memcached jest dość podatny na ataki, szczególnie jego starsze wersje. Nie udostępniaj więc tego systemu buforowania danych poza obręb swojego serwera. Nie odblokowuj żadnych jego portów na firewallu, wszystkie połączenia powinny być nawiązywane w obrębie serwera.

Plik konfiguracyjny memcached znajdziesz w /etc/memcached.conf wyedytuj go i podnieś limit według poniższego przykładu.

-m 256

Zapisz plik konfiguracyjny i zrestartuj serwer memcached wydając w konsoli polecenie

# sudo systemctl restart memcached

Redis

Ostatni z prezentowanej trójki, wysoce konfigurowalny. Żeby korzystanie z niego było bezpieczne i efektywne, dokonajmy kilku zmian w jego pliku konfiguracyjnym.

Wcześniej jednak wygenerujmy silne hasło dla redis, aby nie stał się on celem dla osób nieupoważnionych do jego użycia.

Do tego celu wykorzystamy openssl :] Wydaj w konsoli polecenie

$ sudo openssl rand 60 | openssl base64 -A

Wygenerowany ciąg znaków użyjesz jako hasła dla redis.

Plik konfiguracyjny serwera Redis znajduje się w katalogu /etc/redis/redis.conf wyedytuj ten plik i dokonaj kilku zmian według poniższych sugestii.

bind 192.168.0.200 127.0.0.1

port 6379

demonize yes

maxmemory 2GB

maxmemory-policy allkeys-lru

requirepass silne-haslo

Zamień adres ip 192.168.0.200 na adres ip swojego serwera (ip prywatne nie publiczne)

maxmemory, możesz zostawić jak ja to ustawiłem 2GB,. Możesz też dostosować pod siebie. Jest to maksymalna ilość pamięci jaką Redis może użyć.

silne-hasło, zamień na ciąg znaków wygenerowany za pomocą polecenia openssl użytego powyżej. Hasło zapisz także w bezpiecznym miejscu np. w LastPass.

Zwróć uwagę na to, czy żadna z opcji konfiguracyjnych nie posiada znaku # na początku np. #maxmemory 2GB, jeśli tak jest, usuń znak #, aby wyglądało to tak, jak w przykładzie powyżej.

Resztę opcji konfiguracyjnych możesz pozostawić bez zmian. Zapisz plik konfiguracyjny i zrestartuj serwer Redis wpisując w konsoli

# sudo systemctl restart redis-server

Sprawdź, czy serwer Redis wystartował poprawnie

# sudo systemctl status redis-server

powinien mieć status Active. Jeśli jest inaczej, sprawdź, czy nie popełniłeś jakiejś literówki podczas zmian w pliku konfiguracyjnym Redis. Popraw błąd, zapisz plik i wystartuj serwer Redis ponownie.

Możliwość wykorzystania tego typu cache, sprowadza się jak już wspomniałem, do włączenia odpowiedniej opcji w panelu administracyjnym strony, lub też dokonania odpowiedniego wpisu w pliku konfiguracyjnym strony. Skrypt strony musi jednak wspierać tego typu możliwość.

Po uruchomieniu cachowania na stronie sprawdź zawsze, jak ona się zachowuje po takiej operacji. W rzadkich sytuacjach, efekt może być odwrotny do zamierzonego z różnych przyczyn. Jest to więc bardzo ważne.

Możesz także jego port 6379, odblokować na firewallu jeśli zamierzasz z niego korzystać poza obrębem swojego serwera.

Na zakończenie

Artykuł nie wyczerpuje tematu i przedstawia niejako podstawy do tego, aby twoja strona była szybka i korzystanie z niej było dla odwiedzającego przyjemnością. Sposoby tu zawarte, są dość proste do wdrożenia i sprawdzą się na większości waszych serwerów.

Przyczyn wolnego działania strony może być wiele i nie sposób je tu wszystkie wymienić, podając przy okazji złoty środek na rozwiązanie problemu. Takie zagadnienia jak optymalizacja zapytań do bazy danych, czy też rekonfiguracja samego serwera www niejako na miarę (dokładnie pod wymagania naszych stron internetowych), to tematy zbyt skomplikowane, aby je rzetelnie opisać w tym artykule.

Dość znaczna różnica jest także między optymalizacją nowej, powstającej dopiero strony, a starej, często zaniedbanej i pozostawionej przez dłuższy czas samej sobie. Stąd też zawarte tu informacje nie zawsze mogą się sprawdzić w tym drugim przypadku.

Czy uruchamianie serwerów cachujących dla naszych stron, jest niezbędne podczas stawiania serwera na Raspberry Pi5 ?

Ciężko jednoznacznie odpowiedzieć na to pytanie, bo to zależy od „wolnych” zasobów jakie możemy na nie przeznaczyć, i czy w ogóle będziemy to w stanie zrobić. Odpowiem więc dość wymijająco, jest to bardzo wskazane. Jeśli tylko twój serwer nie pracuje „na oparach” to powinieneś to zrobić.

Nawet, gdy obciążenie twojego serwera jest bardzo wysokie, powinieneś taki cache uruchomić i podpiąć pod niego swoje strony. Z dużym prawdopodobieństwem może się okazać, że w wyniku tego, obciążenie serwera i zużycie pamięci spadnie.

Jak to możliwe ? Podczas dużego obciążenia i gdy serwer „nie wyrabia”, tworzą się kolejki zadań do wykonania, rośnie Load i zużycie pamięci. Gdy tylko ilość wykonywanych operacji na serwerze spadnie w wyniku wykorzystania cache, kolejki przestaną się tworzyć i spadnie ilość wykorzystanych zasobów jak np. pamięć ram.

Rozpatrując problem może się okazać, że przeznaczenie nawet niewielkiej ilości pamięci na cache np. 64mb może pomóc uzdrowić sytuację.

Taki przykład. jakiś czas temu przejąłem pod opiekę jeden z serwerów vps na jakim stoi dość wymagający sklep na PrestaShop. Obciążenie często sięgało 100%, co powodowało ubicie procesów MySQL. Wdrożenie cache, a także rekonfiguracja serwera www spowodowały spadek średniego obciążenia serwera ze 100% do około 10%. Sklep od 3 lat działa bez większych problemów wynikających z nadmiernego obciążenia serwera.

Co prawda oprócz wdrożenia cache, dość gruntowną rekonfigurację przeszedł także sam serwer www. Według mojej opinii jednak samo wdrożenie cache, to 60% sukcesu, reszta była wynikiem optymalizacji działania samego serwera www.

Czy warto więc wdrożyć cachowanie stron internetowych na serwerze? Powyższy przykład chyba dosadnie pokazuje, że jak najbardziej.

Serwer www na Raspberry Pi5 z dostępem do internetu cz. 1

Serwer www na Raspberry Pi5 z dostępem do internetu cz. 2

Serwer www na Raspberry Pi5 z dostępem do internetu cz. 3

Serwer www na Raspberry Pi5 z dostępem do internetu cz. 4

Serwer www na Raspberry Pi5 z dostępem do internetu cz. 6