Mam stronę magento. Nie ma żadnych użytkowników (maksymalnie 2-3 naraz).
Nasz serwer to: CPU: 2000 MHz RAM: 2048 Mb HDD: 50000 Mb.
Zainstalowałem ZendServerCE (apc + memcached + Zend Optimizer + Zend Data Cache). Wyłączyłem memcached, ponieważ strona ładowała się znacznie gorzej. W konsoli administracyjnej ustawiam strukturę typu płaskiego, ponownie indeksowane i buforowane dane.
Mam więc apc + Zend Optimizer + Zend Data Cache .
Pierwszym problemem jest sprawdzenie, jak działa środowisko uruchomieniowe. Wywołanie start_session () zajmuje około 500-700 ms. Wydaje się, że nie jest to dobry wynik. Dlaczego tak długo, nie wiem.
Przeczytałem ten: http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_key_buffer_size i wymyśliłem optymalne opcje dla mojego serwera.
Na godzinę:
Key_read_requests = 8887
Key_reads = 252
Key_write_request = 187
Key_writes = 146
Widzisz, że 252/8887> 0,01, ale nie za dużo. To optymalna wartość, jaką kiedykolwiek dostałem. Inne wyniki rozpoczęto od> 6.
Oto my.cnf:
key_buffer = 48M
myisam_sort_buffer = 2M
sort_buffer = 2M
read_buffer_size = 2M
join_buffer = 2M
read_rnd_buffer = 2M
max_allowed_packet = 128M
thread_stack = 192K
thread_cache_size = 16
query_cache_type = 1
myisam-recover = BACKUP
max_connections = 50
table_cache = 256
#thread_concurrency = 10
query_cache_limit = 8M
query_cache_size = 98M
3. Odczytany z jakiegoś powodu nie był dobry. Wyłączyłem to. Ale pamięć podręczna danych Zend i optymalizator Zend nadal działają.
4 APC wydaje się poprawne. Ładowanie kontrolera zajmuje po raz pierwszy 3-4 sekundy (ustawiam tam die (), aby to sprawdzić) i po raz pierwszy zajmuje to 1 - 1,3 sekundy.
5 Po kilku minutach zrestartowałem mysql i uzyskałem dobry wynik. Strony ładowały się od 1,5 do 2,5 sekundy. Ale teraz (po kilku godzinach) zajmuje to 6–10 sekund. Nie mogę znaleźć przyczyny.
Widzisz tutaj jakąś niepoprawną konfigurację? Może mój serwer nie nadaje się do Magento?
AKTUALIZACJA 1: obecnie około 600 kategorii i 1000 produktów oraz około 20000 kategorii (dla różnych sklepów internetowych) i 1500-3000 produktów w przyszłości.
Nie ma wielu atrybutów.
AKTUALIZACJA 2 Zorientowałem się, że konsola ssh działa zbyt wolno. Ponownie uruchomiłem serwer i teraz działa szybko. oznacza to, że mam problem z pamięcią RAM. Nie ma wystarczającej ilości miejsca.
Jest to stan początkowy bez apache:
total used free shared buffers cached
Mem: 2048 600 1447
AKTUALIZACJA 3 Mam to. Teraz jest ładowany przez 0,5-1,5 sek
Oto konfiguracja: mysql
[mysqld]
key_buffer_size = 256M
tmp_table_size = 32M
max_heap_table_size = 32M
myisam_sort_buffer = 4M
sort_buffer = 4M
read_buffer_size = 4M
join_buffer = 4M
read_rnd_buffer = 4M
max_allowed_packet = 64M
thread_stack = 192K
thread_cache_size = 16
query_cache_type = 1
myisam-recover = BACKUP
max_connections = 20
table_cache = 1024
innodb_buffer_pool_size = 128M
query_cache_limit = 24M
query_cache_size = 256M
php
[apc]
apc.stat=1
apc.enabled=1
apc.optimization=0
apc.cache_by_default=1
apc.shm_segments=10
apc.shm_size=256M
apc.ttl=0
apc.user_ttl=0
apc.num_files_hint=10000
;apc.mmap_file_mask="/tmp/apc"
apc.max_file_size=5M
apc.enable_cli=1
apc.mmap_file_mask="/tmp/apc.XXXXXX"
apc.slam_defense=0
apc.user_entries_hint=10000
Wszystko działa idealnie, ale pozostaje jedno pytanie. APC pokazuje mi tę statystykę:
Dlaczego uderza tak małe? Jakieś pomysły?
źródło
xhprof
i spróbowałem uzyskać wizualizację tego, co zajmuje najwięcej czasu. Czy jest to serwer produkcyjny pod obciążeniem, czy tylko do testowania?Odpowiedzi:
Ponieważ wydaje się, że pytanie nie jest zbyt magento-centryczne, oto moja niezbyt magento-centryczna odpowiedź.
Buforowanie OpCode i optymalizacje DB są dobrym sposobem na przyspieszenie do pewnego stopnia twoich aplikacji internetowych. Ale korzyści będą względnie umiarkowane. Aby uzyskać prawdziwy wzrost prędkości, należy rozważyć użycie pamięci podręcznej lakieru. Jest to oprogramowanie typu open source, łatwe do skonfigurowania i łatwe do zintegrowania z Magento dzięki łatwo dostępnym modułom do Magento.
Jest też dobry artykuł z krótkim omówieniem tego, jak to działa: http://www.fabrizio-branca.de/make-your-magento-store-fly-using-varnish.html
Szczególnie zwróć uwagę na tabelę:
źródło
Jeśli Twoja firma polega na dobrej wydajności hostingu, dlaczego próbujesz administrować serwerem bez doświadczenia.
Z pewnością skorzystasz po prostu kontaktując się ze specjalistycznym hostem Magento i pozwalając mu zająć się administracją systemu, podczas gdy robisz to, w czym jesteś dobry, zarządzając sklepem.
Patrząc na specyfikację, nie masz wystarczającej ilości pamięci RAM, aby spróbować uruchomić sklep Magento. Istnieje wiele podobnych pytań, takich jak twoje,
https://serverfault.com/a/400748/113375 .
/server/430565/magento-hosting-on-a-budget
źródło
Czy to fizyczny sprzęt czy wirtualny prywatny serwer? Prawdopodobnie powinieneś przenieść swoją bazę danych na własny serwer dedykowany. Daje to również korzyść z możliwości ustalenia, czy problemy z szybkością dotyczą Apache / PHP czy MySQL.
spowolnienie start_session () oznacza, że prawdopodobnie cierpisz z powodu słabego sprzętu. Nie wiem, czy wybrane przez ciebie technologie oznaczają, że sesje są przechowywane na dysku lub w pamięci RAM, ale 500-700 ms prawie na pewno oznacza, że są one przechowywane na dysku i masz problemy z wydajnością we / wy - prawdopodobnie dlatego, że twoja baza danych jest zamiana na dysk, ponieważ nie zmieści się w pamięci RAM ... ale to wszystko spekulacje.
Powodzenia!
źródło
free -m
powie ci, czy w ogóle używasz zamiany, a najnowsze wersjetop
polecenia powiedzą ci, czy naciśnij O i P, aby zamówić przez użycie zamiany. W przeciwnym razie musisz wrócić do używania identyfikatora procesu mysqld z czymś takim:awk '/^Swap:/ { SWAP+=$2 } END { print SWAP" kB" }' /proc/$(pidof mysqld)/smaps
Wszystko opisane tutaj: dbasquare.com/2012/04/10/…Oczywiście nie ma sposobu, aby pokazać ci „działającą konfigurację”, która zwiększy twoją wydajność, ale Magento faktycznie próbuje zrobić coś takiego i zamieszcza przykład wysoce skonfigurowanego stosu LAMP w swoich dokumentach wydajności. Metodologia tych oficjalnych dokumentów dotyczy CE i EE. Bardzo polecam przeczytanie obu oficjalnych dokumentów całkowicie, ponieważ sugerowane pomysły odzwierciedlają wiele z tego wątku i zawierają bardzo konkretne rekomendacje Magento, bezpośrednio ze źródła: http://www.magentocommerce.com/whitepaper/
źródło
Konfiguracja
ZendFramework (optymalizator zend i pamięć podręczna danych zend) + APC + Memcache + Nginx
działa idealnie dla mnie.
ponad 30 współbieżnych użytkowników może załadować stronę krócej niż jedną sekundę (~ 0,4s-0,6s)
Ustawiam nginx na 80 portach (jako proxy) i apache na 8080.
Dzięki @MattSchweers za linki. Zapomniałem o tym. Pomaga mi skonfigurować MySQL
źródło
z mojego doświadczenia wynika, że serwer litespeed zwiększa wydajność 2-krotnie wartą 32 USD miesięcznie 1 licencji procesora. Powiedziano mi, że potrzebujesz tylko licencji 1 CPU, ponieważ php działa osobno w litespeed.
źródło
Kiedy masz wiele sklepów internetowych i wiele kategorii, Magento zasadniczo tworzy rodzaj produktu opiekuńczego wpisów dla wszystkich sklepów internetowych, kategorii i produktów, co spowoduje znaczne obciążenie bazy danych. Twoje straty APC są dość wysokie i musisz się tym przyjrzeć. Jednak nawet jeśli naprawisz APC, myślę, że Twój problem z wydajnością może się utrzymywać, szczególnie jeśli zwiększy się ruch. Aby przyspieszyć witrynę, musisz zainstalować pamięć podręczną operacyjną, pamięć podręczną Varnish lub Full page cache (w przypadku wersji Enterprise).
Magento wykonuje wiele operacji odczytu do DB, więc możesz także spróbować ustawić MySQl w trybie replikacji Master Slave, który miał wszystkie odczyty magento z urządzenia podrzędnego, podczas gdy zapisy odbywały się w trybie master.
źródło
Spróbowałbym zmienić następujące opcje APC i sprawdzić, czy trafienia wzrosną.
apc.shm_segments 1
apc.ttl 7200
apc.user_ttl 7200
W witrynie na żywo możesz również użyć następujących opcji.
stan apc. 0
Spowoduje to zatrzymanie sprawdzania przez APC, czy plik zmienił się od czasu jego ostatniej kompilacji, co zapewni przyjemne przyspieszenie. Tylko nie zapomnij opróżnić pamięci podręcznej APC podczas edycji plików PHP.
źródło
Kilka innych myśli. Możesz zwiększyć swój rozmiar innodb_buffer_pool_size, 128M może być nieco niski, a nawet małe witryny mogą rosnąć dość szybko. Zmienna określa, ile twoich danych jest przechowywanych w pamięci.
Magento używa tego do wszystkich swoich tabel, w tym tabel dzienników, które rosną szybko. Konieczne będzie ograniczenie ilości przechowywanych danych. Uruchomienie „php shell / log.php --status” z wiersza poleceń da ci wyobrażenie, gdzie jesteś i czy wymyka się spod kontroli. Istnieją również opcje czyszczenia tabel dzienników.
2 GB pamięci RAM to niewiele do pracy, więc musisz uważać, gdzie przydzielić pamięć.
Również pamięć podręczna pełnej strony + podgrzewacz pamięci podręcznej mogą pomóc w utrzymaniu szybkiego katalogu z katalogami witryny i stronami cms. Możesz zobaczyć nasz tutaj: http://ecommerce.brimllc.com/full-page-cache-magento.html
źródło