![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 260 Pomógł: 41 Dołączył: 6.04.2009 Skąd: Gdańsk/okolice Ostrzeżenie: (0%) ![]() ![]() |
Na wstępie, sorry za taki ogólny opis - nie za wiele mogę zdradzić - warunki umowy...
Do rzeczy. Podczas opracowywania nowego projektu zaświtała mi w głowie myśl, żeby cachować wyniki (niektórych) zapytań SQL. Dla uproszczenia dalszych rozważań, przyjmuję, że wszystko (tj apache/mysql/pliki) jest na jednej fizycznej maszynie. Raz dwa napisałem banalną klasę - przy zapytaniu o pobranie danych, sprawdź czy jest dla tego cache, jeśli nie - pobierz i wygeneruj cache. Jeśli dane się zmieniają - po prostu usuń plik cache. Przedmiotem tego cache są dane ściśle związane z użytkownikiem. Pięknie, działa - ponad 20 razy szybciej niż pobieranie danych z MySQL, choć zapytanie to tak naprawdę złączenie dwóch tabel po id użytkownika. Pięknie, fajnie - ale dla jednego użytkownika. Wobec powyższego, pytanie moje brzmi - jak się może zachować taki banalny cache w momencie, kiedy z serwisu korzysta ok 15000 użytkowników, regenerowanie cache przy aktualizowaniu danych? 15k użytkowników = 15k plików ekstra, które trzeba "wyszukać", wczytać, usunąć - choć nie przewiduję plików większych niż 1KB. Moje największe obawy są związane z dyskiem - czas dostępu, w pewnym sensie "szeregowość" odczytu tych plików... czy przypadkiem przy takim obciążeniu taki cache nie zacznie bardziej szkodzić niż pomagać? Potraktujcie proszę powyższe jako problem "abstrakcyjny" - nawet przy dobrych rezultatach w obecnym projekcie czegoś takiego nie wdrożę, ale w przyszłości? kto wie... I na koniec podkreślę - w tym konkretnym przypadku nie interesują mnie inne metody cache niż dump danych do pliku. jest tu wiele osób o większej wiedzy niż moja - rozwiejcie moje wątpliwości ;) |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 566 Pomógł: 35 Dołączył: 21.06.2006 Ostrzeżenie: (0%) ![]() ![]() |
Cache na plikach jest wręcz wymagany ale musisz dobrze zastanowić się nad tym jak ma on wyglądać - cachowanie po np. 100B danych jest lekko bez sensu (sam MySQL cachuje zapytania w ramie).
Warto cachować treść która jest jak najbardziej niezmienna, np. w przypadku CMSu ja cachuję podstrony ale nie do końca kompletne - zawierają one wszystkie pobrane dane z wyłączeniem treści generowanej przez pluginy oraz np. komentarzy (to zmienia się za często aby replikować cały cache). Pamiętaj też, że cache plikowy powinien być jak najbliżej formy wyjściowej - jego zapis może być wolny ale odczyt musi być jak najszybszy, toteż cachowanie danych raw z sql ma mały sens - lepiej cachować już dane przetworzone nawet kosztem duplikacji pewnych treści. Miej na uwadze także, że duża ilość plików w jednym katalogu (tak jest w przypadku *nixów, nie wiem jak win32) mocno spowalnia proces odczytu. -------------------- flexiCMS v2 [|||||||+--] 75% done
|
|
|
![]()
Post
#3
|
|
![]() Grupa: Zarejestrowani Postów: 307 Pomógł: 37 Dołączył: 9.11.2010 Skąd: Zielona Góra Ostrzeżenie: (0%) ![]() ![]() |
Taki mechanizm jest juz wbudowany w samego MySQL'a i nie sądze aby chciało ci sie pisać cos bardziej rozbudowanego. Musisz jedynie pamiętać aby nie używać cacheowania na zapytanuiach używających losowych wartości lub aktualnych timestamp'ów bo to zabije dysk twardy serwera i pochłonie ogrom czasu na wyszukiwanie/katalogowanie:)
|
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 260 Pomógł: 41 Dołączył: 6.04.2009 Skąd: Gdańsk/okolice Ostrzeżenie: (0%) ![]() ![]() |
ależ ja wiem, że cache jest wymagany
![]() dokładnie wiem jak działa itepe idede Cache poszczególnych stron jest, korzystam z opensourcowego CMSa, ale zastanawiam się jak mogę go przyspieszyć. Tutaj chodzi mi tylko o cache poszczególnych zapytań SQL. Wyniki zapytań serlializuję i wrzucam do pliku. Chodzi mi tylko i wyłącznie o przypadek dumpowania i regenerowania takiego cache w przypadku dużego obciążenia - specyfika projektu jest taka, że 15k użytkowników może logować się i edytować dane, które są w cache - w jednym momencie. Nie chciałbym zabić dysku ![]() W chwili obecnej testowo mam cache dla jednego zapytania, w przypadku kolejnych + moment krytyczny = regeneraja N x 15k plików. Plus - wszelki cache pochodzący od samego CMSa, sam silnik... nie za dużo operacji I/O na raz? |
|
|
![]()
Post
#5
|
|
![]() Grupa: Zarejestrowani Postów: 1 798 Pomógł: 307 Dołączył: 13.05.2009 Skąd: Gubin/Wrocław Ostrzeżenie: (0%) ![]() ![]() |
Jeżeli masz możliwość, możesz zrobić ramdisk, nie musi on być wielki, o ile tych danych nie będzie dużo. Jeżeli nie możesz grzebać w ustawieniach serwera żeby zrobić ramdisk, wydaje mi się że dorzucenie APC przez administratora tego serwera nie powinna być niczym skomplikowanym i swoje cache przechowywać w APC. APC z kolei przechowuje swoje dane w pamięci ram
![]() |
|
|
![]() ![]() |
![]() |
Aktualny czas: 20.08.2025 - 09:18 |