Ehcache
Ehcache jest opartym o open-source narzędziem służącym do zwiększania wydajności oraz odciążenia bazy danych używanym do cach'owania Java. Umożliwia wykorzystanie dla pamięci podręcznej w rozmiarze nawet do 1 terabajta. Ehcache jest efektywnie rozwijany w projekcie terracotta i jest dostępny na licencji Apache 2. Poza w pełni funkcjonalnego wydania open-source w terracotta oferowane jest również profesjonalne wsparcie i doradztwo oraz usługi szkoleniowe całodobowo przez siedem dni w tygodniu.
Ehcache jest biblioteką wprowadzoną w 2003 rok. Celem tego rozwiązania jest poprawa wydajności przez zmniejszenie obciążenia podstawowych zasobów. Narzędzie to pozwala nie tylko na ogólne buforowanie ale również odrębne buforowanie Hibernate (cache drugiego poziomu) obiektów dostępu do danych, poświadczeń bezpieczeństwa oraz stron internetowych. Można go również wykorzystać do buforowania serwera SOAP i REST zapewniając trwałość aplikacji i buforowanie dystrybuowane
.
SOAP czyli Simple Object Access Protocol jest protokołem wymiany uporządkowanych informacji mający m zastosowanie w sieciach komputerowych. Opiera się na Extensible Markup Language(XML) i dalej przekazywany jest przez inne warstwy aplikacji i protokoły np. HTTP i SMTP do negocjacji transmisji i przesyłania wiadomości. Więcej na temat SOAP (http://en.wikipedia.org/wiki/SOAP).
Cache
Cache można określić jako magazyn rzeczy jakie mogą być potrzebne w przyszłości oraz możliwy jest do nich natychmiastowy dostęp (dane dostępne od ręki na potrzeby działania aplikacji). Z informatycznego punktu widzenia jest to zbiór tymczasowych danych w skład których mogą wchodzić duplikaty danych znajdujących się w innym miejscu lub mogą to być również wyniki obliczeń. Dzięki cache dane mogą być od razu dostępne niskim kosztem. Encyklopedycznie – mechanizm, w którym ostatnio pobrane dane dostępne są ze źródła o wysokiej latencji i niższej przepustowości oraz sa przechowywane w pamięci o lepszych parametrach. Pamięć podręczna na chwilę obecna jest składnikiem praktycznie wszystkich systemów począwszy od procesora , który posiada 2 lub 3 poziomy pamięci podręcznej, która oddziela go od pamięci RAM. Dostęp do dysku jest buforowany w pamięci RAM, a dokumenty http buforują się przy użyciu pośredników http i przeglądarki. Zwiększona wydajność osiągana przez buforowanie pojawia się dzięki lokalności odwołań. Zakłada się, że jeżeli nastąpiło odwołanie do pewnych danych, istnieje duże prawdopodobieństwo, iż w bliskiej przyszłości będą one potrzebne ponownie. Niektóre systemy pamięci podręcznej starają się z wyprzedzeniem przewidzieć , które dane będą potrzebne i pobierają je wyprzedzając żądania.
Więcej o pamięci podręcznej : http://pl.wikipedia.org/wiki/Pami%C4%99%C4%87_podr%C4%99czna
Dlaczego buforowanie "cache" działa?
Dopóki w pamięci podręcznej znajdują się obiekty Java przesyłane zostają bezpośrednio z pamięci podręcznej procesora do systemu DNS. Dzieje się tak dlatego ponieważ większość systemów informatycznych wykorzystuje lokalne referencje odnoszące się do lokalnych danych które znajdują się blisko lub właśnie zostały użyte i można je użyć ponownie.
Long Tail - Długi ogon ...
Chris Anderson na łamach "Wired Magazine" użył terminu "Long Tail" (długi ogon) w odniesieniu do systemów e-commerce. Idea obejmowała tezę, iż dla przykładu w dużej ilości produktów (lub innych obiektów) umieszczonych w sklepie internetowym zawsze będzie grupa tych najbardziej popularnych, które są często wyświetlane przez użytkowników i właśnie ta nie wielka w porównaniu z całością liczba produktów może stanowić większość sprzedaży. Identycznie sprawa ma się np. w platformie blogowej, gdzie jedne blogi są bardziej popularne od pozostałych. W związku z powyższym pomimo tego, że istnieje mała lista "obiektów" o dużej popularności to za nimi ciągnie się długi ogon "obiektów", które są mniej popularne.
Jak sama nazwa wskazuje „Long Tail” opiera się o teorię prawdopodobieństwa rozkładu popularności danych obiektów („power law” - http://en.wikipedia.org/wiki/Power_law). Rozkład ten pojawia się nie tylko w przypadku e-commerce ale ma odniesienie do całej natury. Jedna z form „Power law” jest rozkład Pareto
- http://pl.wikipedia.org/wiki/Rozk%C5%82ad_Pareto
- http://www.serwisy.umcs.lublin.pl/dorota.stankiewicz/Wykaz%20Rozkladow.pdf,
- http://www.statsoft.pl/textbook/stathome_stat.html
- hhttp%3A%2F%2Fwww.statsoft.pl%2Ftextbook%2Fstdisfit.html
Ogólnie mówiąc „rozkład Pareto” obejmuję proporcje 80:20. Zjawisko to ma zastosowanie w buforowaniu. Jeżeli 20% obiektów zabiera 80% czasu i uda się znaleźć sposób obniżający „koszt” pozyskania tych 20% obiektów wydajność systemu znacznie się poprawi.
Czy należy zasilać aplikację z pamięci podręcznej ?
Najkrócej mówiąc – TAK , ze względu na występowanie długiego ogonu. Lepiej jest umieścić częściej wykorzystywane obiekty w miejscu o szybszym dostępie co znacznie skróci czas ich załadowywania. Rozwijając odpowiedź można również powiedzieć, iż skuteczność buforowania zależy od wielu czynników takich jak rodzaj i moc procesora czy powiazania wejścia/wyjścia (I/O). Jeżeli aplikacja opiera swoje działanie często zapisując i odczytując dane dodając do tego jeszcze czas potrzebny na wykonanie obliczeń czas jaki potrzebny jest na wykonanie przez nią pracy zależy głównie od tego
z jaką prędkością możliwe jest uzyskanie dostępu do potrzebnych danych. Jeżeli natomiast działanie aplikacji polega na wykonywaniu wielu operacji obliczeniowych czas pracy zleżał będzie od możliwości oferowanych przez procesor oraz dostępna pamięć.
Ideą buforowania jest skupienie się na poprawie wydajności to warto również zdawać sobie sprawę, że poprzez stosowanie bufora zmniejszone zostaje również obciążenie. Czas jaki jest potrzebny aplikacji na wykonanie czegoś przekłada się zwykle na „koszt” jaki trzeba ponieść by ta operację wykonać. Tak, więc zadaniem buforowania jest odciążenie ograniczonych zasobów przy zwiększeniu wydajności.
Przyspieszamy …
Szybsze i wydajniejsze działanie aplikacji zwykle można osiągnąć stosując:
- Efektywniejsze algorytmy w kodzie aplikacji
- Rozłożenie obliczeń na wielu procesorach i/lub wielu maszynach (klastry)
- Zastosowanie szybszych i wydajniejszych procesorów
Zadaniem pamięci podręcznej będzie natomiast przechowanie i szybkie udostępnienie danych będących wynikiem obliczeń wykonywanych przez aplikację oraz udostępnienie obiektów, które mogą być wykorzystane ponownie. Przykładowo Ecache będzie miał zastosowanie do przechowywania dużych stron internetowych, których wczytywanie zabiera większość czasu i zwiększa „koszty” utylizacji. Innym przykładem może być przechowywanie w buforze stanu uwierzytelnienia szczególnie jeżeli użyte zostały metody kryptograficzne.Dużo aplikacji pracuję na zasadzie wejścia/wyjścia, operacji dyskowych oraz sieciowych jeżeli dodać do tego wykorzystanie baz danych ograniczenie wydajności może być spowodowane wszystkim wymienionym powyżej. Niestety dla szybkości działania dysków nie sprawdza się prawo Moora. Dysk pracujący z szybkością 10000 RPM uważano jako szybki kilka lat emu i teraz nadal się tak uważa. Przyspieszenie w dyskach realizowane jest przy użyciu dyskowych buforowanych bloków pamięci. Co do operacji sieciowych na czas działania wpływ ma kilka czynników takich jak czas potrzebny na utworzenie i zamknięcie połączenia, występujące opóźnienia wynikające z zastosowanych technologii sieciowych, ograniczona przepustowość i wiele innych. Buforowanie danych przyda się poprawiając działanie operacji przy użyciu wejścia/wyjścia umożliwiając znacznie szybszy dostęp do obiektów , stron internetowych oraz stron generowanych z bazy danych.
Zwiększenie skalowalności aplikacji
Następnym atutem zwiększania wydajności aplikacji stosując buforowanie jest również zwiększenie skalowalności aplikacji. Zakładając , że mamy bazę danych, do której możliwe jest wykonanie 100 zapytań na sekundę gdzie każde nawiązane połączenie tworzy się dokonuję zapisu w bazie i następnie wygasa. Buforując tego rodzaju operację można spowodować , że 90 ze 100 nawiązywanych połączeń trafi do szybko dostępnej pamięci podręcznej przez co skala możliwości bazy zostanie zwiększona 10 krotnie.
O ile szybciej zadziała aplikacja stosując buforowanie ?
Przyspieszenie zależy od wielu czynników :
- Ile razy dany fragment danych znajdzie się w pamięci podręcznej i jak często jest wykorzystywany przez aplikację
- Ilość czasu przez jaki dany fragment danych znajduje się w buforze
Większość aplikacji biznesowych najczęściej wykonuję operację odczytu i zapisu (I/O) do baz danych
i większość czasu tracone jest właśnie na połączenie do bazy danych oraz odczytanie lub zapisanie informacji. W tym miejscu przyspieszenie zależy głównie od tego ile fragmentów danych da się wykorzystać ponownie umieszczając je w pamięci podręcznej. W środowisku gdzie każdy kawałek danych używany jest jednorazowo przyspieszenie z zastosowaniem bufora będzie zerowe, ale w systemie wykorzystującym dane ponownie przyspieszenie będzie na wysokim poziomie. Bardziej szczegółowa odpowiedź wymaga przytoczenia bardziej skomplikowanych matematycznych obliczeń.
Prawo AMDAHL
Prawo Amdahla nazwane tak od nazwiska twórcy używane jest do znajdywania maksymalnego
i spodziewanego zwiększenia wydajności całkowitej systemu jeżeli tylko część systemu została ulepszona.
Więcej na temat prawa Amdahla - http://pl.wikipedia.org/wiki/Prawo_Amdahla
Topologie cache
Ecache stosowany jest w następujących topologiach :
- Standalone
- Distributed Ehcache
- Commerce
Topologia standalone.
Buforowanie danych odbywa się na danej instancji serwera gdzie znajduję się aplikacja. Poszczególne instancję mogą być buforowane niezależnie bez możliwości komunikowania się pomiędzy nimi.
Topologia Distributed Ehcache
Buforowane dane przechowywane są w tablicy serwera terracotta z podzbiorem ostatnio używanych elementów w każdej instancji pamięci podręcznej dla aplikacji. Topologie rozproszone obsługiwane są przez bardzo bogaty zestaw trybów zgodności.
Topologia Commerce
Zestaw danych zostaje buforowany na każdej instancji aplikacji oraz dane mogą być kopiowane lub usuwane w obrębie całego klastra bez blokowanie. Replikacja może być synchroniczna lub asynchroniczna.
Aplikacje biznesowe ze względu na ich dostępność i skalowalność instalowane są na wielu instancjach serwera często konfigurowanych jako klaster. Jednak bez rozpowszechnienia i powielenia bufora pamięci podręcznej występuję szereg niepożądanych zachowań takich jak :
Drift Cache, czyli każda instancja utrzymuje własna pamięć podręczną a aktualizacja w jednej z nich nie zostaje przeniesiona do drugie i dzieje się tak również w obrębie nawiązanej sesji internetowej.
Database bottlenecks czyli wąskie gardło w bazie danych wynikające z niereplikujących się buforów oraz powodujące powielające się zapytania z rożnych instancji.
Buforowanie rozproszone
Ehcache swoje możliwości ukazuję wraz z zastosowaniem tablicowego serwera terraccota. Zapewnia rozproszone buforowanie, umożliwiające współdzielenie danych między wieloma cacheManagerami oraz buforuję wiele JVM na raz. Połączenie Ehcache z możliwościami serwera terraccota umożliwia :
- Liniowe skalowanie aplikacji rosnące wraz z wymaganiami
- Buforowane dane pozostają spójne w ramach klastra
- Odciążenie bazy danych i zmniejszenie „kosztów”
- Zwiększenie wydajności aplikacji wykorzystując rozproszone dane w pamięci podręcznej
- Dostęp do potężnego API
Korzystanie z rozproszonego buforowania jest zalecana metodą pracy Ehcache w klastrze zapewniające najwyższą wydajność, dostępność i skalowalność.
Poza wbudowane w Ehcache buforowanie rozproszone istnieją również dodatkowe mechanizmy replikacji pamięci podręcznej dostępne w postaci dodatków np.:
· RMI
· JGroups
· JMS
· Server Cache
Ehcache 1.5 wspiera Server Cache Ehcache. Aby skorzystać z udostępnionych danych wszystkie JVM muszą mieć możliwość odczytu i zapisu w serwerze pamięci podręcznej , który uruchomiony jest wewnątrz danego procesu JVM. By osiągnąć redundancję wewnątrz serwera Ehcache możliwe jest skonfigurowanie go w klastrze. Technika klastra rozszerzona została w wersji Ehcache 1.6
Komentarze
Prześlij komentarz