Szybkość: Magento z APC i Memcached

Przebadaliśmy wiele forów i nie znamy odpowiedzi na następujące pytania. Mamy oba APCi Memcachezainstalowane na naszych serwerach. Nie jesteśmy pewni, jaka jest poprawna i najlepsza konfiguracja.

Moje pytanie

Jakie są / są najlepsze ustawienia do uruchamiania Magento przy użyciu jednocześnie Memcache + APC? (Czy to wcale nie jest mądre)

Badania podstawowe

Tutaj Memcache i APC są zalecane jako szybka i wolna pamięć podręczna (ale bez dysku). Wygląda na to, że działa to tylko wtedy, gdy masz wystarczającą ilość pamięci RAM (i pewne)

• http://www.coeusblue.com/blog/48-magento/65-magento-caching

A ten artykuł dotyczy Memcache lub APC - i mamy jedno i drugie

• http://magebase.com/magento-tutorials/speeding-up-magento-with-apc-or-memcached/

I tutaj stwierdza, że ​​Memcache naprawdę działa tylko wtedy, gdy zdefiniowano również powolny backend

• http://www.magentocommerce.com/boards/viewthread/283908/#t393090

I myślę, że ten artykuł mówi to samo

• http://www.byte.nl/blog/speeding-up-magento-the-burden-of-two-level-cache/

To jest rozwiązanie mojego lokalnego dostawcy dla pliku local.xml

<cache>
  <backend>apc</backend>
  <prefix>sitenamehere__</prefix>
</cache>
<cache>
  <backend>memcached</backend>
  <memcached>
    <servers>
      <server>
        <host><![CDATA[127.0.0.1]]></host>
        <port><![CDATA[11211]]></port>
        <persistent><![CDATA[1]]></persistent>
      </server>
    </servers>
    <compression><![CDATA[0]]></compression>
    <cache_dir><![CDATA[]]></cache_dir>
    <hashed_directory_level><![CDATA[]]></hashed_directory_level>
    <hashed_directory_umask><![CDATA[]]></hashed_directory_umask>
    <file_name_prefix><![CDATA[]]></file_name_prefix>
  </memcached>
</cache>

Sytuacja

Zainstalowany hosting współdzielony Brim FPC: http://ecommerce.brimllc.com/full-page-cache-magento.html (ten FPC ma również skalowalną pamięć podręczną plików, aby była bardziej złożona)

Musisz zrozumieć wyraźne rozróżnienie między tymi dwoma produktami, aby zrozumieć, jak z nich korzystać.

• APC to zarówno pamięć podręczna OPCode, jak i szybki backend
• Memcache to tylko szybki backend

Używanie APC jako pamięci podręcznej OPCode

Po prostu zainstaluj moduł na swoim serwerze

pecl install apc

I włącz to w swoim php.ini

echo "extension=apc.so" >> /usr/lib/local/php.ini       (RedHat/Centos)
echo "extension=apc.so" >> /etc/php5/conf.d/20apc.ini   (Debian)

Następnie włącz i dostosuj konfigurację środowiska wykonawczego do potrzeb, np.

apc.enabled
apc.shm_segments
apc.shm_size
apc.optimization
apc.num_files_hint
apc.user_entries_hint
apc.ttl
apc.user_ttl
...

Następnie uruchom ponownie PHP / Apache

/etc/init.d/httpd restart                               (RedHat/Centos)
/etc/init.d/apache2 restart                             (Debian)

Po tym nie ma już nic więcej do roboty. Potwierdź, że APC jest włączony za pomocą szybkiego phpinfo()- ale w przeciwnym razie w tym momencie część pamięci podręcznej OPCode w APC jest aktywna.

Po stronie Magento nie trzeba nic konfigurować.

Używanie APC jako szybkiego zaplecza

Musisz dodać następujące elementy do swojego ./app/etc/local.xml

<global>
  ...
  <cache>
    <backend>apc</backend>
      <prefix>mystore_</prefix>
  </cache>
  ...
</global>

Następnie opróżnij istniejące pamięci podręczne sklepów. Aby sprawdzić, czy działa, załaduj stronę w interfejsie, a ./var/cachekatalog powinien pozostać pusty.

Używanie Memcache jako szybkiego zaplecza

Musisz zainstalować Memcache jako rozszerzenie PHP i zainstalować odpowiedni Demon Memcache (Memcached) na swoim serwerze.

pecl install memcache

I włącz to w swoim php.ini

echo "extension=memcache.so" >> /usr/lib/local/php.ini            (RedHat/Centos)
echo "extension=memcache.so" >> /etc/php5/conf.d/20memcache.ini   (Debian)

/etc/init.d/httpd restart                               (RedHat/Centos)
/etc/init.d/apache2 restart                             (Debian)

Następnie zainstaluj Memcached na serwerze. W przypadku RH / Centos dostosuj adres URL do wersji i architektury procesora.

rpm -Uhv http://apt.sw.be/redhat/el6/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
yum --enablerepo=rpmforge install memcached

apt-get install memcached                               (Debian)

Następnie zmodyfikuj Magento, aby używał Memcache jako szybkiego zaplecza, zmień ścieżkę gniazda na połączenie TCP / IP, aby pasowało.

<cache>
  <slow_backend>database</slow_backend>

  <fast_backend>memcached</fast_backend>
  <fast_backend_options>
    <servers>
      <server>
        <host>unix:///tmp/memcached.sock</host>
        <port>0</port>
        <persistent>0</persistent>
      </server>
    </servers>
  </fast_backend_options>

  <backend>memcached</backend>
  <memcached>
  <servers>
    <server>
      <host>unix:///tmp/memcached.sock</host>
      <port>0</port>
      <persistent>0</persistent>
    </server>
  </servers>
</cache>

Ostrzeżenia dotyczące Memcache i tagowania - co to jest

Memcache obsługuje tylko jeden poziom relacji klucz-wartość, więc nie może przechowywać tagów pamięci podręcznej Magento (używanych do niezależnego opróżniania pamięci podręcznej). W rezultacie musisz albo określić, slow_backendaby utrzymać relację znacznika zawartości pamięci podręcznej, albo w ogóle jej nie definiować.

Jeśli zdefiniujesz a slow_backend, ryzykujesz, że tagi pamięci podręcznej staną się tak duże, że wydajność zostanie zanegowana; istnieje również nieodłączny problem, którego nie można skalować na wielu serwerach, jeśli każdy serwer utrzymuje własne tagi pamięci podręcznej.

Dlatego przy korzystaniu z Memcache lepszym podejściem (z zastrzeżeniem, że nie można samodzielnie opróżniać pamięci podręcznych), jest nie zawracać sobie głowy używaniem slow_backend.

W takim przypadku zalecamy usunięcie <slow_backend>database</slow_backend>i zastąpienie go:

  <slow_backend>Memcached</slow_backend>
  <slow_backend_options>
    <servers>
      <server>
        <host>unix:///tmp/memcached.sock</host>
        <port>0</port>
        <persistent>0</persistent>
      </server>
    </servers>
  </slow_backend_options>

Spowoduje to uszkodzenie / wyłączenie 2. poziomu buforowania (i zapobiegnie przechowywaniu tagów), ale nadal pozwoli na wydajność Memcache.

Którego użyć

Jeśli jest to wdrożenie na jednym serwerze - użycie APC do wszystkiego nie zaszkodzi.

Jeśli jest to konfiguracja rozproszona - musisz użyć Memcache jako szybkiego zaplecza (aby wszystkie maszyny miały dostęp do wspólnego sklepu).

Bardziej niepokojące jest to, że jeśli twój dostawca hostingu nie może powiedzieć ci, która konfiguracja jest właściwa, z pewnością masz niewłaściwy host.

Atrybucje: sonassi.com , php.net , repoforge.org

Zgadzam się z poprzednimi odpowiedziami, ale tutaj jest krótka precyzja: Tak, apc może być używany zarówno jako silnik pamięci podręcznej, jak i jako optymalizator kodu bajtowego PHP. Należy jednak wyjaśnić dwie kwestie:

• Jako szybki backend, dyrektywami konfiguracji używanymi przez APC do zrozumienia, jak musi zapisywać dane, zarządza się za pomocą dyrektyw apc.user_%. Pozostałe dotyczą tylko pamięci podręcznej kodu bajtów (np. Czas wygaśnięcia pamięci podręcznej opcodu, apc.user_ttl: czas wygaśnięcia danych przechowywanych w pamięci podręcznej twojego Magento).

• Jako szybki backend APC zachowuje się dokładnie tak samo jak memcached: nie zarządza tagami pamięci podręcznej, a dla Magento wymaga skonfigurowanego wolnego backendu (lub domyślnie używa pliku wolnego backendu).

Z mojego doświadczenia wynika, że ​​na stronach o dużym ruchu, jeśli używasz apc tylko jako optymalizatora kodu bajtowego, potrzebujesz wartości między 96 a 256Mo w wartości konfiguracyjnej apc.shm_size. Zwiększ również apc.num_files_hint z 1000 do 15000: domyślnie pamięć podręczna apc cache tylko 1000 plików, a Magento domyślnie zawiera około 20 000 plików PHP i PHTML ( find . -type f -name "*.php" -o -name "*.phtml" | wc -l). Dostosuj tę wartość do swojego kodu źródłowego.

Jeśli używasz APC lub memcached jako szybkiego zaplecza, trudno jest podać kilka wskazówek dotyczących wymaganej pamięci: tak naprawdę zależy to od polityki pamięci podręcznej zastosowanej w Twojej instancji.

Na razie konfiguracja pamięci podręcznej działa w następujący sposób:

• każda treść jest przechowywana zarówno w pamięci podręcznej, jak i w pliku
• Szybki backend jest zawsze wymagany przed powolnym backendem
• jeśli nic nie zostanie znalezione w szybkim backend, magento szuka w wolnym backend

Dlaczego te dwa poziomy zarządzania? memcached i inne szybkie backendy to magazyny pamięci. Oznacza to, że dane mogą zostać uszkodzone lub zniknęły.

Jak zwiększyć wydajność tej konfiguracji?

Wyłącz drugie pisanie jest prawdopodobnie jedną z najbardziej wydajnych opcji. Wyjaśnia to czwarty wspomniany artykuł. Ale nie można używać kodu źródłowego slow_backend_store_data bez modyfikacji. W twoim kontekście nie zalecam dostosowywania z następujących powodów: twoje dane przechowywane w pamięci podręcznej nigdy nie będą kontrolowane. Będziesz przechowywać dane w pamięci, zyskasz na wydajności, ale być może wyślesz swoim odwiedzającym nieprawidłową treść. Musisz więc znaleźć rozwiązanie, które zapewni ci dostęp do pamięci (dla lepszej wydajności), kontrolę zapisu i możliwość wyłączenia buforowania slow_backend_store_data. Możesz dotrzeć do tego kontekstu poprzez:

• zamień serwer memcached na serwer redis (redis może sterować odczytem i zapisem, tak jak robi to system plików), i nadal używaj apc jako optymalizatora kodu bajtowego

• * upewnij się, że możesz użyć opcji slow_backend_store_data * , dostosowując kod źródłowy lub przełączając się na powolny backend bazy danych (tak, zwiększa obciążenie serwera bazy danych, ale jeśli zasady pamięci podręcznej są dobrze zdefiniowane, nie powinno być problem)

• * dezaktywuj opcję slow_backend_store_data * : w tej konfiguracji nie jest już wymagane, masz kontrolę odczytu i zapisu wykonaną przez redis.

Jako dodatkową uwagę do tego stwierdziliśmy, że podczas korzystania z APC z Magento (do buforowania opcode - używamy Redis do konwencjonalnego buforowania stron i bloków Magento), ważne jest, aby upewnić się, że ustawienie statystyki wynosi 0 w produkcji (ale 1 w rozwój):

apc.stat = 0

Ustawienie apc.stat służy do określania, czy należy sprawdzić skrypt dla każdego żądania w celu ustalenia, czy został zmodyfikowany ( http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat ), a więc ustawienie tej wartości na 0 w środowisku produkcyjnym przyniesie korzyści w zakresie wydajności APC nie wykonującej tej kontroli przy każdym żądaniu.

Warto zauważyć, że gdy apc.stat jest ustawiony na 0, prawdopodobnie będziesz musiał ponownie uruchomić proces serwera WWW, aby pobrać zmiany plików (tj. Po wdrożeniu), ale i tak powinno to być częścią Twojej strategii po wdrożeniu.

Najlepszą rzeczą, jaką zrobiliśmy, aby znacznie przyspieszyć backend, jest zainstalowanie REDIS jako modułu obsługi pamięci podręcznej . Jest teraz obsługiwany również w rdzeniu od Magento 1.8 i nowszych.

Nic nie może się równać ... teraz jest kliknięcie kliknięcie kliknięcie kliknięcie

http://www.magentocommerce.com/knowledge-base/entry/redis-magento-ce-ee

Ponadto możesz rozważyć dodanie rozszerzenia Redis Session, aby dodać także sesje do serwera pamięci Redis ...

Powodzenia!

Z tego pliku local.xml Magento odbierze ostatni wpis i użyje Memcache. Myślę, że istnieje pomieszanie między tym, jak APC i Memcache mogą współpracować z Magento.

Po pierwsze, APC ma 2 zastosowania:

• buforowanie opcode - skompiluj pliki php w opcode, dzięki czemu wykonywanie skryptu jest o około 25% szybsze
• przechowywanie kluczy / wartości - może być używane przez Magento jako system pamięci podręcznej.

Z drugiej strony Memcache to tylko magazyn kluczy / wartości. Dużą zaletą Memcache jest to, że może pracować w trybie klient-serwer, więc wiele serwerów frontendowych może korzystać z tej samej pamięci podręcznej, co jest konieczne, jeśli masz wiele serwerów obsługujących tę samą stronę internetową.

Najczęstszą konfiguracją jest instalacja APC, aby uzyskać buforowanie opcode (aby uzyskać ~ 25% szybsze wykonanie skryptu) i używać Memcache jako serwera pamięci podręcznej. Użyłem również APC jako systemu pamięci podręcznej i chociaż teoretycznie powinien on być nieco szybszy niż Memcache, nie można odróżnić.