TurboGears - buforowanie

Aby zwiększyć wydajność aplikacji internetowej, zwłaszcza jeśli jest ona zaangażowana w długotrwałe operacje, stosuje się techniki buforowania. TurboGears udostępnia dwa rodzaje technik buforowania -

Whole-page Caching

Działa na poziomie protokołu HTTP, aby uniknąć całych żądań do serwera, ponieważ przeglądarka użytkownika lub pośredni serwer proxy (taki jak Squid) przechwytują żądanie i zwracają buforowaną kopię pliku.

Application-level Caching

Działa to w serwerze aplikacji, aby buforować obliczone wartości, często wyniki złożonych zapytań do bazy danych, dzięki czemu przyszłe żądania mogą uniknąć konieczności ponownego obliczania wartości. W przypadku aplikacji internetowych buforowanie na poziomie aplikacji zapewnia elastyczny sposób buforowania wyników złożonych zapytań, dzięki czemu całkowite obciążenie danej metody kontrolera można zredukować do kilku zapytań specyficznych dla użytkownika lub przypadku oraz narzutu renderowania szablonu .

Buforowanie na poziomie aplikacji

Jak wspomniano wcześniej, projekt TurboGears „Szybki start” jest skonfigurowany tak, aby umożliwić pakiet Beaker do obsługi buforowania. Beaker obsługuje następujące back-endy używane do przechowywania pamięci podręcznej -

memory- Używany do przechowywania na proces. Jest niezwykle szybki.
filesystem - przechowywanie na proces, jak również wieloprocesowe.
DBM database - na proces, wiele procesów, dość szybko.
SQLAlchemy database- pamięć masowa na serwer bazy danych. Wolniej w porównaniu do podanych powyżej opcji.
Memcached - wieloserwerowa pamięć podręczna oparta na pamięci.

Buforowanie kontrolera

W celu szybkiego buforowania kontrolera plik cached()dekorator jest dostępny. Cała treść kontrolera jest buforowana w zależności od różnych parametrów żądania. Definicjatg.decorators.cached() dekorator jest następujący

tg.decorators.cached(key, expire, type, 
   query-args, cache_headers, invalidate_on_startup, cache_response)

Opis parametrów jest następujący -

Sr.No.	Parametry i opis
1	key Określa parametry kontrolera używane do generowania klucza pamięci podręcznej.
2	expire Czas w sekundach do wygaśnięcia pamięci podręcznej, domyślnie „nigdy”.
3	Type dbm, memory, file, memcached lub None.
4	cache_headers Krotka nazw nagłówków wskazujących nagłówki odpowiedzi.
5	invalidate_on_startup Jeśli prawda, pamięć podręczna jest unieważniana za każdym razem, gdy aplikacja jest uruchamiana lub restartowana.
6	cache_response odpowiedź powinna być buforowana lub nie, domyślnie True.

Poniżej znajduje się przykład buforowania kontrolera -

@cached(expire = 100, type = 'memory')
@expose()
def simple(self):
   return "This is a cached controller!"

Buforowanie na poziomie szablonów

Silnik szablonów Genshi pobiera szablon z pamięci podręcznej, jeśli jego zawartość nie uległa zmianie. Domyślny rozmiar tej pamięci podręcznej to 25. Domyślnie automatyczne ponowne ładowanie szablonów jest prawdziwe. Aby poprawić wydajność, w programie można wprowadzić następujące ustawieniaapp_cfg.py -

[app:main]
genshi.max_cache_size = 100
auto_reload_templates = false

Aby zapisać szablon w pamięci podręcznej, wystarczy zwrócić plik tg_cache opcja z kontrolera, który renderuje buforowany szablon.

Tg_cache to słownik, który akceptuje następujące klucze -

key - Klucz pamięci podręcznej. Default: Żaden.
expire - jak długo cache musi pozostać żywy. Default: nigdy nie wygasa
type - pamięć, dbm, memcached. Default: dbm.

Poniższy przykład ilustruje buforowanie szablonów -

@expose(hello.templates.user')
def user(self, username):
   return dict(user = username, tg_cache = dict(key = user, expire = 900))