.
Proces instalacji jest bardzo prosty:
# wget http://xcache.lighttpd.net/pub/Releases/1.3.1/xcache-1.3.1.tar.gz
# tar zxf xcache-1.2.2.tar.gz
# cd xcache-1.2.2
# phpize
# ./configure --enable-xcache
# make && make install
Ale nie obyło się bez nieprzewidzianych trudności. Po pierwsze, phpize nie został znaleziony na początku. Jak się okazało konieczna była instalacja pakietu php-devel ( #yum install php-devel ). Po drugie, wystąpił błąd na etapie kompilacji - kompilator przeklął brakujący plik nagłówkowy timelib_config.h . Po krótkich poszukiwaniach w Google znaleziono rozwiązanie: w pliku /usr/include/php/ext/date/lib/timelib_structs.h trzeba było wymienić
#włączać
#include "timelib_config.h"
Dalszy montaż i instalacja przebiegły bez problemów. Pozostało tylko dodać ustawienia dla XCache do /etc/php.ini (bez namysłu wziąłem je z artykułu do którego link był podany powyżej, tylko w linijce zend_extension podmieniłem ścieżkę na własną: /usr/lib/php/modules/xcache.so).
Następnie sprawdziłem wydajność PHP za pomocą polecenia php -m i wszystko zadziałało!
Potem pozostawało już tylko zrestartować Apache i cieszyć się efektem. Wysiłek się opłacił: strony zaczęły działać szybciej (jednak mogę to ocenić tylko subiektywnie, nie przeprowadzałem dokładnych pomiarów) i zużywać mniej pamięci. W szczególności mój TextCMS zamiast 320 Kb na stronę zaczął zużywać tylko 120!
Przykład ustawienia parametrów:
;; zainstaluj jako rozszerzenie zend (zalecane), zwykle „$extension_dir/xcache.so”
zend_extension = /usr/local/lib/php/extensions/no-debug-non-zts-20060613/xcache.so
xcache.admin.enable_auth = Wł
xcache.admin.user = "mooo"
; xcache.admin.pass = md5($twoje_hasło)
xcache.admin.pass=""
; ini tylko ustawienia, wszystkie wartości tutaj są domyślne, chyba że wyjaśniono
; wybierz implementację schematu shm/alokatora niskiego poziomu
xcache.shm_scheme = "mmmap"
; aby wyłączyć: xcache.size=0
; aby włączyć: xcache.size=64M itd. (dowolny rozmiar> 0), a mmap systemu na to pozwala
xcache.size = 32M
; ustaw liczbę procesorów (cat /proc/cpuinfo |grep -c procesor)
xcache.liczba = 1
; tylko wskazówki dotyczące skrótu, zawsze możesz przechowywać liczbę (przedmioty)> gniazda
xcache.slots = 8K
; ttl elementu pamięci podręcznej, 0=na zawsze
xcache.ttl=0
; interwał skanowania gc wygasłych elementów, 0=brak skanowania, inne wartości w sekundach
xcache.gc_interval = 0
; tak samo jak powyżej, ale dla zmiennej pamięci podręcznej
xcache.var_size = 0M
xcache.var_count = 1
xcache.var_slots = 8K
; domyślny ttl
xcache.var_ttl=0
xcache.var_maxttl=0
xcache.var_gc_interval = 300
xcache.test = Wył
; Nie dotyczy dla /dev/zero
xcache.readonly_protection = wyłączone
; dla *nix, xcache.mmap_path to ścieżka do pliku, a nie do katalogu.
; Użyj czegoś takiego jak „/tmp/xcache”, jeśli chcesz włączyć funkcję ReadonlyProtection
; 2 grupy php nie będą współdzielić tego samego /tmp/xcache
; dla win32, xcache.mmap_path=anonimowa nazwa mapy, a nie ścieżka do pliku
xcache.mmap_path = "/dev/zero"
; pozostaw puste (wyłączone) lub „/ tmp/phpcore/”
; upewnij się, że jest zapisywalny przez php (bez sprawdzania open_basedir)
xcache.coredump_directory = ""
; na żądanie ustawienia
xcache.cacher = Wł
xcache.stat = Wł
xcache.optimizer = Wył
; na żądanie ustawienia
; włącz zbieranie danych o zasięgu dla funkcji xcache.coveragedump_directory i xcache_coverager_start/stop/get/clean() (zaburzy wydajność wykonywania)
xcache.coverager = Wył
; tylko ustawienia ini
; upewnij się, że jest czytelny (care open_basedir) przez skrypt przeglądarki zasięgu
; wymaga xcache.coverager=Wł
xcache.coveragedump_directory = ""
Jak wiesz, PHP jest językiem interpretowanym, tj. za każdym razem, gdy uzyskuje się dostęp do skryptu, ten skrypt jest kompilowany. Jeśli masz 1 skrypt, nie ma się czym martwić, ponieważ czas kompilacji nie jest duży. Ale w nowoczesnych CMS-ach i frameworkach podczas wyświetlania strony używa się 10-300 oddzielnych plików php (innymi słowy zawiera). Im więcej obejmuje i im są one cięższe, tym dłużej trwa proces kompilacji.
Aby rozwiązać ten problem, wymyślili przechowywanie skompilowanej postaci skryptu w pamięci. Istnieją specjalne moduły do przechowywania skompilowanego kodu w pamięci. Nazywa się je akceleratorami.
Najbardziej znane: eAccelerator, APC, XCache. Każdy ma swoje wady i zalety. Używam XCache, ponieważ jest najszybszy i najbardziej niezawodny. Chociaż każdy ma swoje zdanie na temat niezawodności.
Niektóre akceleratory pozwalają przechowywać w pamięci nie tylko skrypty, ale także wyniki obliczeń. Na przykład selekcje z bazy danych. W praktyce wygląda to jak przechowywanie pamięci podręcznej w Memcache . Ale używam Memcache - tak jest historycznie.
Administrator XCache
XCache posiada mały panel administracyjny do wyświetlania statystyk i resetowania pamięci podręcznej. Zwykle znajduje się tutaj /usr/local/share/examples/xcache/admin/. Dlatego musisz przenieść ten folder gdzieś do katalogu głównego witryny lub do panelu administracyjnego, aby móc go oglądać z poziomu przeglądarki. Możesz pobrać administratora.
Tak to wygląda dla mnie
Pierwsza tabela przedstawia ogólne statystyki. Są w nim 2 linie, ponieważ mam 2-rdzeniowy procesor, a XCache rozdziela pamięć podręczną na oba rdzenie. Łącznie mam przydzielone 512 mln.
Panel administratora może dać błąd Błąd krytyczny: xcache_count(): xcache.admin.user i xcache.admin.pass
Masz więc włączoną autoryzację w konfiguracji xCache.
Najłatwiej to wyciąć. Jestem sam na swoim serwerze i nie muszę ustawiać haseł wewnątrz serwera.
Autoryzacja jest wyłączona w konfiguracji xcache.admin.enable_auth = Off
Konfiguracja xCache zwykle znajduje się w /etc/php5/conf.d/xcache.ini
Po edycji konfiguracji musisz zrestartować Apache.
statystyki xcache
z powrotem do panelu administracyjnego (patrz obrazek powyżej).
automaty- liczba miejsc na pamięć podręczną. W ten sposób rozumiem, ile części bije przydzielona pamięć. W moim przypadku jest to 8000. Im większa ta wartość, tym szybsze jest wyszukiwanie, ale wymaga więcej pamięci.
rozmiar- rozmiar pamięci pod XCache
Wykorzystać- ile pamięci pozostało. Jak widać nie mam. Zapełnione całe 512 Mb
Jasny- przycisk czyszczenia pamięci podręcznej
Hity- ile wykonano dostępów do plików
Tęsknie- ile wykonano dostępów do plików, ale tych plików nie było w pamięci. To normalny proces. Pliki się zmieniają - wylatują z pamięci podręcznej. Ale w moim przypadku wszystkie pliki po prostu nie mieszczą się w pamięci, więc ich tam nie ma, a zatem są chybienia.
Chodaki- jak rozumiem, ile razy wnioskowaliśmy o jakieś pliki do skrytki, ale w tym czasie te pliki były jeszcze kompilowane, tj. była blokada.
OOM- ile razy pliki nie dostały się do pamięci podręcznej z powodu braku pamięci.
Buforowane- liczba plików w pamięci podręcznej. W sumie mam 6400 plików.
ustawienia xcache
Kilka słów o tym, ile pamięci należy przydzielić. Początkowo przeznaczyłem 128 Mb, ale ta pamięć zapełniła się w 10 minut. Dlatego przydzieliłem 512 Mb i ten wolumen został już zapełniony w 1 godzinę. Wydawać by się mogło, że można przeznaczyć 1 Gb i wtedy wszystko pasowałoby dokładnie. Ale jest tylko 4 GB pamięci i lepiej przeznaczyć ją na MySQL (więcej na ten temat). Co więcej, pliki, które nie były buforowane przez godzinę, są rzadko używanymi skryptami. Po prostu są strony, które dziennie odwiedza 10-100 osób i można się tam obejść bez buforowania. Jest to tak zwany „długi ogon”, który jest rzadko używany, ale zajmuje dużo miejsca. W moim przypadku jest to 3% (chybienia/trafienia).
O czym jeszcze nie należy zapominać. Załóżmy, że zmieniłeś kod w dużym projekcie. Miejsce w pamięci zostało zwolnione, a pliki rzadko odwiedzanych projektów mogą być zapisywane w tym pustym miejscu. W związku z tym pliki dużego projektu nie trafią do pamięci podręcznej. Mówiąc najprościej, XCache NIE jest w stanie śledzić, które pliki można wyrzucić z pamięci podręcznej i umieścić w ich miejsce częściej żądane pliki (jest to tak zwana „gorąca” pamięć podręczna). Dlatego musisz ręcznie zresetować pamięć podręczną za pomocą panelu administracyjnego.
Poniższa tabela pokazuje, które pliki są buforowane i jak skutecznie.
Hity- liczba wywołań tego skryptu w pamięci. Im większy tym lepszy. Jeśli dla niektórych plików ta wartość jest mniejsza niż 10 przez długi czas, to ten plik jest rzadko używany i zajmuje tylko miejsce w pamięci.
rozmiar to rozmiar tego pliku w pamięci. Oto najciekawsze. Okazuje się, że skompilowany plik zajmuje 10 razy więcej miejsca w pamięci niż na dysku. O mój Boże!
Rozmiar źródła- rozmiar pliku na dysku
Dostęp- jak dawno uzyskano dostęp do tego pliku
Tworzyć- jak długo ten plik jest w pamięci podręcznej
Moja konfiguracja
xcache.size = 512M
xcache.liczba = 2
xcache.slots = 8K
xcache.ttl=0
xcache.gc_interval = 0
xcache.var_size = 0M
xcache.var_count = 2
xcache.var_slots = 8K
xcache.var_ttl=0
xcache.var_maxttl=0
xcache.test = Wył
xcache.cacher = Wł
xcache.stat = Wł
Jak widać wyłączyłem używanie XCache jako buforowania wyników obliczeń (xcache.var_size = 0M). Do tego mam Memcache.
No i faktycznie wyniki: przyspieszenie 2-3 razy. Jeśli wcześniej strona była generowana w 0,3 sekundy (wliczając Memcache), teraz jest to 0,1 sekundy. To jest przykład z jednego projektu na CMS LiveStreet. 
Buforowanie kodu bajtowego za pomocą akceleratorów PHP znacznie zwiększa wydajność serwera i reakcję na żądania klientów. Istnieje kilka popularnych akceleratorów PHP, spośród których nasz wybór padł na XCache.
Większość ludzi wie, że PHP działa jak tłumacz tłumaczący - tj. najpierw skrypt jest analizowany, następnie jego zawartość jest tłumaczona na kod bajtowy (http://ru.wikipedia.org/wiki/Bytcode), a dopiero potem wynik jest interpretowany i zwracany.
Akceleratory PHP raz utworzony kod bajtowy jest przechowywany w pamięci podręcznej przez określony czas w celu późniejszego ponownego użycia, jeśli oryginalna krypta nie podlegała zmianom. W ten sposób PHP eliminuje 2 etapy pracy: parsowanie skryptu i jego tłumaczenie na kod bajtowy - w obecności kodu bajtowego PHP w pamięci podręcznej pozostaje tylko jego interpretacja i zwrócenie wyniku. A fakt, że kod bajtowy jest przechowywany/buforowany w pamięci RAM, daje raczej namacalny wzrost wydajności.
Istnieje kilka innych popularnych akceleratorów dla PHP, APC ( Najnowsza wersja beta: 3.1.13 (2012-09-03)) i eAccelerator ( Najnowsza stabilna wersja: 0.9.6.1 (2010-05-31)), które są uważane za potencjalnie martwe, dlatego ich stosowanie jest wysoce odradzane. Na przykład w przypadku eAcceleratora, chociaż zadeklarowano obsługę PHP 5.4, podczas korzystania z niego zauważono powtarzające się usterki, które wydawały się wyrażać w błędzie HTTP 500 na niektórych stronach internetowych, które działały dobrze po wyłączeniu eAcceleratora.
Do tej pory XCache jest najbardziej idealnym kandydatem, który obsługuje wszystkie wersje PHP, w tym PHP 5.6.
Lista akceleratorów PHP - Wikipedia, wolna encyklopedia: http://en.wikipedia.org/wiki/List_of_PHP_accelerators
Instalacja i wstępna konfiguracja XCache w systemie Linux
Możesz zainstalować XCache w systemie Linux z następujących pakietów:
$ mniam zainstaluj php-xcache xcache-admin $ apt-get zainstaluj php5-xcache
xcache.ttl i xcache.var_maxttl domyślnie = 0, tj. żywotność pamięci podręcznej jest nieograniczona, co naszym zdaniem nie jest dobre IMHO, skrypty można już usunąć, a pamięć podręczna zamarznie, zajmując taką pamięć RAM, której każdy potrzebuje. Ustawmy więc czas życia pamięci podręcznej na 24 godziny (86400 sekund), z interwałem wyrzucania elementów bezużytecznych „ *gc_interval ” równym 3600 sekund. (jedna godzina):
$ vi / etc/ php.d/ xcache.ini [ xcache-common] extension = xcache.so [ xcache.admin] xcache.admin.enable_auth = wyłączone xcache.admin.user = "admin" xcache.admin.pass = [ xcache] xcache.shm_scheme = "mmap" xcache.size = 60M xcache.count = 1 xcache.slots = 8K xcache.ttl = 86400 xcache.gc_interval = 3600 xcache.var_size = 4M xcache.var_count = 1 xcache.var_slots = 8K xcache .var_ttl = 0 xcache.var_maxttl = 86400 xcache.var_gc_interval = 3600 xcache.var_namespace_mode = 0 xcache.var_namespace = "" xcache.readonly_protection = wyłączone xcache.mmap_path = "/tmp/xcache" xcache.coredump_directory = "" xcache.coredump_type= 0 xcache.disable_on_crash = wyłączone xcache.experimental = wyłączone xcache.cacher = włączone xcache.stat = włączone xcache.optimizer = wyłączone [xcache.coverager] xcache.coverager = wyłączone xcache.coverager_autostart = włączone xcache.coveragedump_directory = "" $service httpd ponownie uruchomić
Możesz sprawdzić, czy XCache został pomyślnie zainstalowany za pomocą skryptu php, którego wyniki powinny zawierać wiersze z parametrami konfiguracyjnymi XCache:
Szczegóły dotyczące opcji konfiguracyjnych tutaj: http://xcache.lighttpd.net/wiki/XcacheIni#INIsettingsforXCache
Instalowanie panelu administracyjnego XCache
Panel administratora XCache przydatne na początkowym etapie, kiedy nie zaszkodzi sprawdzić efektywność wykorzystania pamięci podręcznej i czy jest na to wystarczająca ilość przydzielonej pamięci RAM ( pamięć o swobodnym dostępie), a potem panel administracyjny można usunąć na wiele lat.
Panel administracyjny XCache to prosty zestaw skryptów PHP, a jeśli pakiet xcache-admin został zainstalowany, te same skrypty PHP panelu administracyjnego będą dostępne w /usr/share/xcache , które można skopiować do katalog web, którego potrzebujemy (cp - r /usr/share/xcache /var/www/html/), lub lepiej po prostu utwórz alias dla wirtualnego hosta, którego potrzebujemy:
< virtualhost ...>... Alias /xcacheadmin "/usr/share/xcache/"< Directory "/usr/share/xcache/" >Opcje Indeksy MultiViews FollowSymLinks AllowOverride All Kolejność zezwalaj, odmawiaj Zezwalaj wszystkim
Teraz utwórzmy skrót MD5 hasła i edytujmy nasz xcache.ini ( lub php.ini) b i zrestartuj serwer:
$ echo -n "tajnehasło" | md5sum - $ vi /etc/php.d/ xcache.ini[xcache.admin] xcache.admin.enable_auth=Włączony xcache.admin.user="admin" xcache.admin.pass= "3cb1cc80547422c9ef667953f00e9a17"$ /etc/init.d/ restart httpd
Panel administracyjny XCache powinien być teraz dostępny pod adresem http://my-host.com/xcacheadmin. Ale w moim przypadku autoryzacja się nie powiodła, a panel administracyjny XCache ciągle powtarzał „Uwierzytelnianie nie powiodło się”.
Według niektórych raportów (#339 (xache3.1.0 Repeat pop-up windowwymaga uwierzytelnienia) – XCache) problem jest związany z tym, że HTTP_AUTHORIZATION nie dociera do backendu. Komuś niby pomogło .htaccess z linijką "SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0", ale postanowiono "zapunktować" te wszystkie problemy i całkowicie wyłączyć "xcache.admin.enable_auth = Off" tę nieprawidłową autoryzację XCache i użyć to bezpośrednio z tego samego .htaccess:
AuthUserFile "/ścieżka/do/.htpasswd" AuthName "Tylko administrator" AuthType Podstawowe wymaga ważnego użytkownika Spełnij wszystkie #Zamów zezwolenie,odmów #Zezwalaj od xxx. xxx. xxx. xxx
UWAGA! Oznacza to, że statystyki panelu administracyjnego, jak i samo buforowanie kodu bajtowego, nie są globalne, ale dotyczą wyłącznie każdego wirtualnego hosta (domeny) z osobna.
Jeśli panel administracyjny nie jest dostępny z pakietów, to można go „wyrwać” z archiwum kodu źródłowego (katalog httpd), więcej szczegółów pod linkami:
- InstallAdministration-XCache
- http://xcache.lighttpd.net/wiki/InstallAdministration
- http://xcache.lighttpd.net/wiki/GettingSource
XCache usuwa pamięć podręczną co 10 minut
Jeżeli w czasie istnienia pamięci podręcznej xcache.ttl liczba trafień (Hits) w statystykach korzystania z buforowanego kodu bajtowego nie wzrasta, a rozmiar dostępnej (wolnej, dostępnej) pamięci RAM nie zmniejsza się lub wskaźniki te są regularnie (po 5-10 minutach) resetuj do zera, Oznacza to, że coś trzeba poprawić w ustawieniach.
Pamięć podręczna XCache jest resetowana po każdym ponownym uruchomieniu serwera (przeładowanie, płynne lub ponowne uruchomienie). Niektóre osoby, zamiast dokładnego i rozważnego dostrajania serwera, po prostu pozostawiają domyślne konfiguracje i walczą z regularnymi wyciekami pamięci i awariami serwera za pomocą płynnego polecenia apachectl wykonywanego przez crona. Dlatego najpierw musisz sprawdzić zadania cron pod kątem poleceń, które ponownie uruchamiają serwer WWW.
Jeśli w koronie nie ma nic podejrzanego, musisz pogrzebać w konfiguracji serwera, a zwłaszcza jeśli skrypty na nim działają, czyli FastCGI:
$ vi / etc/ httpd/ conf.d/ fcgid.conf # FcgidProcessLifeTime 3600 FcgidProcessLifeTime 0 # domyślnie: FcgidIdleTimeout 300 FcgidIdleTimeout 86400 # Domyślnie: FcgidMaxRequestsPerProcess 0 #musi być<= PHP_FCGI_MAX_REQUESTS FcgidMaxRequestsPerProcess 0 ... DefaultInitEnv PHP_FCGI_CHILDREN 1
Powyższa konfiguracja to działająca konfiguracja, w której czas życia i maksymalna liczba żądań dla procesów Fcgid nie są sprawdzane (tj. = 0), z wyjątkiem sprawdzania procesów oczekujących, a mianowicie, czy proces oczekujący na żądanie nie otrzyma żądania w ciągu FcgidIdleTimeout ( 24 godziny.), następnie zostanie zabity, a XCache odpowiednio zresetowany.
Problem z regularnym opróżnianiem pamięci podręcznej pojawił się, gdy niektórzy użytkownicy zdecydowali się używać XCache do przechowywania sesji, a ponieważ domyślne procesy Fcgid były rutynowo zabijane wraz z pamięcią podręczną XCache, użytkownicy ponownie musieli się logować.
Lista Wersje XCache: http://xcache.lighttpd.net/wiki/ReleaseArchive
Admin BagoSeeker jest zagorzałym bojownikiem o wolne od błędów działanie dowolnych mechanizmów i organizmów w całym wszechświecie i dlatego jest w nieustannym poszukiwaniu wszelkiego rodzaju błędów, a ten, kto szuka, jak wiadomo, zawsze znajduje. Gdy czegoś lub kogoś nie da się wyleczyć, wówczas słowami „jestem w piekle, a wy wszyscy diabłami” wpada w obżarstwo, wychodząc z którego ponownie podejmuje się leczenia nieuleczalnego.
Aby przyspieszyć wykonywanie skryptów php, istnieją tak zwane akceleratory, których istotą jest to, że raz wywołany skrypt php jest kompilowany i trafia do pamięci podręcznej akceleratora. Następnie, gdy ponownie uzyskasz dostęp do skryptu, jest on już podany w skompilowanej formie. Co znacznie wpływa na obciążenie serwera, ponieważ teraz nie musisz za każdym razem ponownie kompilować skryptu.
xPamięć podręczna- bardzo dobry moim zdaniem akcelerator PHP, który kilkukrotnie zwiększa szybkość wykonywania skryptów php..
Kilkukrotne użycie akceleratora skraca czas generowania strony, a także zmniejsza obciążenie procesora serwera. Tak więc po skonfigurowaniu Xcache na serwerze ilość używanego czasu procesora zmniejszyła się o prawie dwa. A ponieważ do hostowania moich stron używam serwera wirtualnego, gdzie płacę tylko za korzystanie z zasobów, użycie akceleratora php zmniejsza całkowity koszt wynajmu serwera.
Zacznijmy więc instalować na serwerze akcelerator kodu php - Xcache.
Używam Ubuntu 10.04 na serwerze, ale nowsze, takie jak niedawno wydana Ubuntu LTS 12.04 14.04 Long Term Support, będą wyglądać tak samo. Działa również na Debianie 7.
Zainstalować:
Sudo apt-get install php5-xcache Spowoduje to zainstalowanie najnowszej stabilnej wersji, więc nie musisz niczego kompilować.
Po instalacji otwórz plik konfiguracyjny w /etc/php5/conf.d/xcache.ini
Dla mnie wygląda to tak:
xcache.size = 128M
xcache.liczba = 14
xcache.slots = 8K
xcache.ttl=36000
xcache.gc_interval = 36000
xcache.var_size = 8M
xcache.var_count = 14
xcache.var_slots = 8K
xcache.var_ttl = 36000
xcache.var_maxttl = 604800
xcache.cacher = Wł
xcache.stat = Wł
Główne parametry:
xcache.rozmiar- odpowiada za ilość pamięci do przechowywania pamięci podręcznej. Jeśli wartość jest zbyt mała, efekt buforowania tak naprawdę nie będzie.
xcache.liczba- liczba bloków, na które zostanie podzielona pamięć podręczna. Zaleca się ustawienie według liczby rdzeni procesora.
xcache.sloty- Liczba miejsc na pamięć podręczną, im więcej miejsc, tym szybsze wyszukiwanie w pamięci podręcznej. Ale zużycie pamięci również wzrasta. Zaleca się pozostawienie wartości domyślnej: 8K
xcache.ttl-Czas życia buforowanego obiektu w sekundach. Jeśli nikt nie uzyskał dostępu do obiektu w określonym czasie, obiekt jest oznaczany jako nieużywany, a następnie usuwany z pamięci podręcznej przez moduł wyrzucania elementów bezużytecznych.
xcache.gc_interval- interwał uruchamiania modułu bezużytecznego w sekundach. Określa czas, po którym zostanie uruchomiony moduł wyrzucania elementów bezużytecznych. Po uruchomieniu szuka wpisów z wygasłym okresem istnienia (xcache.ttl) i usuwa je z pamięci podręcznej.
Dwa ostatnie parametry (xcache.ttl i xcache.gc_interval) są bardzo ważne w konfiguracji Xcache, ale na wielu stronach wartości tych parametrów są ustawione na 0, więc nic nie jest usuwane z pamięci podręcznej, a gdy jest pełna , nowe skrypty już do niego nie wchodzą. Oznacza to, że jeśli umieścisz nową witrynę na serwerze, jej skrypty nie będą już trafiać do pamięci podręcznej, ponieważ jest ona całkowicie wypełniona skryptami poprzedniej witryny.
Za buforowanie wyników obliczeń odpowiadają parametry zaczynające się od xcache.var_. A ich parametry są podobne.
Po zapisaniu ustawień uruchom ponownie serwer WWW.
sudo /etc/init.d/apache2 uruchom ponownie
Przeglądanie statystyk Xcache
Xcache posiada własny panel administracyjny, który umożliwia podgląd aktualnego stanu oraz wyczyszczenie pamięci podręcznej.Aby to zadziałało należy skopiować folder admin z /usr/local/share/examples/xcache/admin/ do katalogu swojej strony (Ubuntu)
W Debianie 7 tym katalogiem jest /usr/share/xcache
Ale wcześniej powinieneś ustawić hasło w pliku konfiguracyjnym. Odpowiadają za to parametry.
Xcache.admin.enable_auth
xcache.admin.user="użytkownik"
xcache.admin.pass="hasło"
hasło musi być określone jako md5hash dla większego bezpieczeństwa.
Możesz uzyskać md5hash, wykonując
php echo md5("hasło"); ?> lub możesz uzyskać hash na przykład na stronie http://mainspy.ru/encryption_md5
Sloty - Liczba slotów na cache, im więcej slotów, tym szybsze wyszukiwanie w cache. Ale zużycie pamięci również wzrasta. Zaleca się pozostawienie wartości domyślnej: 8K
rozmiar- rozmiar pamięci pod Xcache.
Wykorzystać- ile pamięci pozostało.
Jasny- Wyczyść pamięć podręczną.
Hity- ile wykonano dostępów do plików
Tęsknie- ile wykonano dostępów do plików, ale tych plików nie było w pamięci.
Chodaki- tymczasowo zablokowane pliki w pamięci podręcznej.
OOM- Liczba plików, które nie mogły dostać się do pamięci podręcznej z powodu braku pamięci.
Buforowane- Całkowita liczba plików w pamięci podręcznej.
Poniższa tabela pokazuje, które pliki są buforowane i jak skutecznie.
Hity- liczba wywołań tego skryptu w pamięci. Im większy tym lepszy. Jeśli dla niektórych plików ta wartość jest mniejsza niż 10 przez długi czas, to ten plik jest rzadko używany i zajmuje tylko miejsce w pamięci.
rozmiar to rozmiar tego pliku w pamięci. Oto najciekawsze. Okazuje się, że skompilowany plik zajmuje 10 razy więcej miejsca w pamięci niż na dysku. O mój Boże!
Rozmiar źródła- rozmiar pliku na dysku
Dostęp- jak dawno uzyskano dostęp do tego pliku
Tworzyć- jak długo ten plik jest w pamięci podręcznej
xCache to program, który buforuje kod bajtowy php w celu optymalizacji i przyspieszenia wykonywania skryptów. Na przykład eAccelerator lub PHP-APC.
Artykuł obejmie podstawową konfigurację. A potem możesz przekręcić parametry zgodnie z własnymi życzeniami.
Nie ma sensu długo czekać na instalację: wszystko odbywa się standardowo.
Aptitude zainstaluj php5-xcache
Podstawowe ustawienia pamięci podręcznej
Pierwszym zadaniem będzie określenie podstawowych ustawień do pracy. Otwórz plik w swoim ulubionym edytorze . Wszystkie parametry są pogrupowane. Aktualnie poszukujemy grupy
xcache.size = 32M
Ta dyrektywa określa całkowitą ilość pamięci dla pamięci podręcznej. Wartość domyślna to 16 megabajtów.
xcache.liczba = 1
Określone przez liczbę procesorów (rdzeni). Dwa rdzenie - zestaw 2. I tak dalej. Lub dwa jednordzeniowe procesory.
xcache.ttl=0
Czas życia pamięci podręcznej. Czasami może być konieczne wyczyszczenie pamięci podręcznej po pewnym czasie. Wartość jest podawana w sekundach.
Rozważ parametry wymagane do buforowania zmiennych. W pewnych warunkach może to być również przydatne.
xcache.var_size = 8M
Całkowita ilość pamięci przydzielonej dla zmiennej pamięci podręcznej. Domyślnie 0 - wyłączone.
xcache.var_count = 1
Ta zmienna jest podobna do xcache.count.
xcache.var_ttl=0
Tutaj możesz również narysować analogię ze zmienną xcache.ttl: ustawia ona czas życia zmiennej cache.
xcache.var_maxttl=0
Ta zmienna określa maksymalny czas życia pamięci podręcznej.
Optymalizator XCache
Czasami może być konieczne włączenie optymalizatora wbudowanego w xCache. Aby to zrobić, należy przekazać następującą dyrektywę od państwa wyłączony w stan na.
xcache.optimizer = włączony
Panel administracyjny dla xCache
xCache jest wyposażony w panel kontrolny, który umożliwia przeglądanie statystyk. Mam kilka nginx + php-fpm, przykład zostanie napisany z myślą o tym.
Przede wszystkim skonfigurowaliśmy nginx. Będzie to wymagało użycia aliasu dla lokalizacji.
Lokalizacja /x/ ( alias /usr/share/xcache/admin/; lokalizacja ~ .php$ ( fastcgi_index index.php; fastcgi_pass unix:/run/php-fpm.sock; zawierać fastcgi_params; fastcgi_param PHP_ADMIN_VALUE "(!LANG:open_basedir =/usr/share/xcache/admin/:/var/php-temp-dir/"; fastcgi_param SCRIPT_FILENAME $request_filename; } } !}
Piszemy konfigurację dla dowolnego wirtualnego hosta, restartujemy nginx: usługa przeładowania nginx. Następnie otwórz stronę w przeglądarce http:// przyklad.com/x/mkhasło.php. Zamień example.com na adres swojej witryny, dla której utworzyłeś alias.
Korzystając z tego skryptu, musisz utworzyć skrót md5 hasła, który będzie używany do uwierzytelniania w panelu administratora xCache. Wystarczy wpisać hasło, kliknąć przycisk „Wyślij zapytanie” i skopiować wynik.
Po wykonaniu wszystkich tych czynności otwórz plik /etc/php5/mods-available/xcache.ini, w grupie edytować niezbędne parametry.
xcache.admin.user="nazwa użytkownika"
Określ nazwę użytkownika, który będzie miał dostęp do panelu administracyjnego.
xcache.admin.pass="..."
Tutaj, w cudzysłowach, musisz podać skrót md5 hasła użytkownika.
Zapisz edytowany plik i uruchom ponownie Apache, php-cgi lub php-fpm.
Administrator xcache powinien być teraz dostępny pod adresem http://example.com/x/. Spróbuj się zalogować i przeglądać statystyki.
- W kontakcie z 0
- Google+ 0
- OK 0
- Facebook 0
