W maju napisałem artykuł o korzystaniu z API WordPress Transients. Podsumowuję artykuł w ten sposób:
Aby zasymulować pliki cookie i ich funkcję wygaśnięcia, opłacalnym rozwiązaniem może być użycie przejściówek WordPress.
https://wordpress.mediadoma.com/pl/uzywasz-przejsciowek-wordpress-zamiast-plikow-cookie/
Chociaż celem artykułu było nakreślenie podstaw, w jaki sposób możemy zaprojektować klasę do pracy z interfejsem API Transients w celu symulacji zachowania plików cookie, jednym z efektów ubocznych artykułu jest to, że nie wykonała dobrej pracy wyjaśnienia, jak działa interfejs API Transients (i, przez proxy, jak działa MySQL).
Zwrócił mi na to uwagę przez e-mail David z UpDraft Plus.
Pomyślałem więc, że warto porozmawiać o koncepcji buforowania z poziomu praktycznego, o tym, jak jest zaimplementowane w WordPress, a następnie przyjrzeć się, jak wykorzystać wtyczki lub nowszą technologię, aby lepiej zasilać nasze witryny i aplikacje, a także lepiej rozumieć.
Zrozumienie buforowania: podstawy
Koncepcja buforowania jest stosunkowo prosta. Ale myślę, że najlepiej to zademonstrować, mówiąc najpierw o serializacji i pobieraniu danych bez buforowania.
Bez buforowania
Zapisywanie danych
Za każdym razem, gdy zapisujesz informacje w bazowej bazie danych, rejestrujesz rekord – lub serię rekordów – w bazie danych.
Na przykład, gdy publikujesz post, zapiszesz rekord w tabeli dla postów i tabeli dla metadanych postu, z których każdy jest powiązany identyfikatorem posta.
W tym poście nie ma znaczenia, w jaki sposób są ze sobą powiązane.
Zamiast tego w tej części należy zrozumieć, że gdy dane są zapisywane w bazie danych, tworzony jest co najmniej jeden rekord, jeśli nie wiele.
Czytanie danych
Gdy odwiedzający ląduje na stronie, aby przeczytać ten konkretny post, wszystkie informacje dotyczące tego posta zostaną pobrane z bazy danych, przesłane do aplikacji WordPress, a następnie wyrenderowane na interfejsie użytkownika.
Pomyśl o tym całym procesie jako o podróży:
- ❓odwiedzający prosi o stronę,
- 🔍 serwer WWW zidentyfikował jaką stronę załadować,
- 📂 strona jest pobierana z bazy danych z wielu tabel,
- 🏗 dane są gromadzone i przesyłane do aplikacji podstawowej,
- 🖥 dane prezentowane są użytkownikowi.
Tak więc podróż zaczyna się, gdy użytkownik zażąda strony i kończy się, gdy informacje są mu prezentowane w przeglądarce.
To podróż
I bez buforowania dzieje się to dla każdego użytkownika. Oznacza to, że dla każdego użytkownika, który odwiedza Twoją witrynę, należy odbyć podróż.
Może to być bardzo kosztowne pod względem zasobów i czasu (szczególnie w zależności od rozmiaru bazy danych).
Ale w tym miejscu może pojawić się buforowanie.
Przed wejściem do buforowania
Ideą buforowania jest przyspieszenie całego procesu. Oznacza to, że jeśli wiemy, że zbliża się wycieczka, możemy przechowywać informacje w takim miejscu, aby były już zebrane i szybsze do odzyskania.
Zanim jednak omówię, co powiem w następnym poście, zauważ, że jest to jak podróż na dysk twardy serwera, na którym hostowana jest witryna, za każdym razem, gdy odwiedzana jest witryna.
Ponieważ ostatecznie baza danych, pliki i wszystkie zasoby niezbędne do zasilania witryny znajdują się na dysku twardym. I tak, takie rzeczy jak dyski półprzewodnikowe mogą przyspieszyć ten proces, ale nadal nie jest tak optymalny, jak to możliwe.
I tu właśnie pojawia się buforowanie. Aby lepiej zrozumieć interfejs API Transients, ważne jest zrozumienie buforowania, które najpierw wymaga podstawowego zrozumienia, jak działają bez buforowania.
To podkład
Potraktuj to więc jako podstawowy element wprowadzający do tego, jak działa witryna oparta na bazie danych bez buforowania. A potem omówimy to bardziej w następnym poście.