Загрузка страницы в Magento занимает слишком много времени

У меня есть сайт Magento. Пользователей нет (максимум 2-3 за раз).

Наш сервер: ЦП: 2000 МГц, ОЗУ: 2048 МБ, жесткий диск: 50000 МБ.

Я установил ZendServerCE (apc + memcached + Zend Optimizer + Zend Data Cache). Я выключил memcached, потому что сайт загружен намного хуже. Я установил структуру плоского типа, переиндексировал и кэшировал данные в консоли администратора.

Так что у меня есть apc + Zend Optimizer + Zend Data Cache .

1. Первая проблема - я проверил во время выполнения, как работает диспетчеризация. Вызов start_session () занимает около 500-700 мс. Кажется, это не очень хороший результат. Почему так долго, я не знаю.

2. Я прочитал это: http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_key_buffer_size и выяснил оптимальные варианты для моего сервера.

В час:

Key_read_requests = 8887
Key_reads         = 252
Key_write_request = 187
Key_writes        = 146 

Вы видите, что 252/8887> 0,01, но не слишком много. Это оптимальное значение, которое я когда-либо получал. Другие результаты начались с> 6.

Вот мой.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. Memcached по какой-то причине не был хорош. Я выключил это. Но кеш данных Zend и оптимизатор Zend все еще работают.

4 APC кажется правильным. Загрузка контроллера в первый раз занимает 3-4 секунды (я установил die (), чтобы проверить это), и в первый раз это займет 1 - 1,3 секунды.

5 Через несколько минут я перезапустил MySQL, я получил хороший результат. Страницы загружались от 1,5 до 2,5 секунд. Но сейчас (через несколько часов) это занимает 6-10 секунд. Я не могу найти причину.

Итак, вы видите здесь неправильную конфигурацию? Может быть, мой сервер не подходит для magento?

ОБНОВЛЕНИЕ 1: около 600 категорий и 1000 продуктов сегодня и около 20000 категорий (для разных интернет-магазинов) и 1500-3000 продуктов в будущем.

Есть не так много атрибутов.

ОБНОВЛЕНИЕ 2 Я обнаружил, что консоль ssh работает слишком медленно. Я перезагрузил сервер, и теперь он работает быстро. значит у меня проблема с оперативной памятью. Недостаточно места.

Это начальный статус без Apache:

             total       used       free     shared    buffers     cached
Mem:          2048        600       1447

ОБНОВЛЕНИЕ 3 Я получил это. Теперь он загружается за 0,5-1,5 сек.

Вот конфигурация: 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

Все работает отлично, но остается один вопрос. APC показывает мне эту статистику:

Почему хиты такие маленькие? Любые идеи?

Поскольку вопрос кажется не слишком ориентированным на magento, вот мой не очень ориентированный на magento ответ.

Кэширование OpCode и оптимизация БД - это хороший способ ускорить работу ваших веб-приложений. Но выгода будет относительно умеренной. Чтобы получить реальный прирост скорости, вы должны рассмотреть возможность использования кэша лака. Это открытый исходный код, его легко конфигурировать и легко интегрировать с magento благодаря свободно доступным модулям для magento.

Есть также хорошая статья с кратким обзором того, как это работает: http://www.fabrizio-branca.de/make-your-magento-store-fly-using-varnish.html

Особенно рассмотрим график:

Если ваш бизнес зависит от эффективности вашего хостинга, почему вы пытаетесь администрировать сервер без опыта?

Вы наверняка выиграете, просто связавшись со специалистом хоста Magento и предоставив им возможность позаботиться о системном администрировании, пока вы делаете то, что умеете, управляя своим магазином.

Глядя на ваши спецификации, у вас недостаточно оперативной памяти, чтобы пытаться запустить магазин Magento. Есть множество подобных вопросов, как у вас,

https://serverfault.com/a/400748/113375 .
/server/430565/magento-hosting-on-a-budget

Это физическое оборудование или виртуальный частный сервер? Возможно, вам следует переместить вашу базу данных на собственный выделенный сервер. Это также дает вам возможность изолировать, связаны ли ваши проблемы со скоростью с Apache / PHP или с MySQL.

start_session () медленный означает, что вы, вероятно, страдаете от недостаточного аппаратного обеспечения. Я не знаю, означает ли ваш выбор технологии, что сеансы хранятся на диске или в ОЗУ, но 500-700 мс почти наверняка означают, что они хранятся на диске, и у вас возникают проблемы с производительностью ввода-вывода - возможно, потому что ваша база данных обмен на диск, потому что он не помещается в оперативной памяти ... но это все домыслы.

Удачи!

Очевидно, что нет способа показать вам «рабочую конфигурацию», которая повысит вашу производительность, но Magento действительно пытается сделать что-то подобное и публикует пример высоко сконфигурированного стека LAMP в своих технических документах. Методология этих технических документов относится к CE и EE. Я настоятельно рекомендую прочитать оба документа полностью, поскольку предложенные идеи перекликаются с большей частью этой темы и содержат очень конкретные рекомендации Magento, непосредственно из источника: http://www.magentocommerce.com/whitepaper/

конфигурация

ZendFramework (Zend-оптимизатор и Zend-кеш данных) + APC + Memcache + Nginx

работает идеально для меня.

более 30 одновременно работающих пользователей могут загрузить страницу менее чем за одну секунду (~ 0,4 с - 0,6 с)

Я установил nginx на 80 порт (как прокси) и apache на 8080.

Спасибо @MattSchweers за ссылки. Я забыл об этом. Это помогает мне настроить MySQL

По моему опыту, сервер litespeed повышает производительность в 2 раза, что стоит $ 1 / месяц лицензии на 1 процессор. Мне сказали, что вам нужна только лицензия 1cpu, так как php работает отдельно в litespeed.

Когда у вас есть несколько интернет-магазинов и несколько категорий, Magento по сути создает своего рода каретный продукт записей для всех интернет-магазинов, категорий и продуктов, что значительно увеличивает нагрузку на базу данных. Ваши промахи APC довольно высоки, и вам нужно изучить это. Однако даже если вы исправите APC, я думаю, что ваша проблема с производительностью может сохраниться, особенно если ваш трафик увеличивается. Чтобы ускорить ваш сайт, вам нужно установить операционный кеш, Varnish или Full page cache (если Enterprise Edition).

Magento выполняет много операций чтения в БД, поэтому вы также можете попытаться, чтобы ваш MySQl в режиме репликации «ведущий-ведомый» имел все чтения magento с ведомого, в то время как запись происходит с ведущим.

Я бы попробовал изменить следующие параметры APC и посмотреть, подхватывают ли попадания.

apc.shm_segments 1

apc.ttl 7200

apc.user_ttl 7200

На живом сайте вы также можете использовать следующее.

apc.stat 0

Это остановит проверку APC, изменился ли файл с момента его последней компиляции, что даст вам хороший прирост скорости. Только не забудьте очистить кэш APC при редактировании файлов PHP.

Пара других мыслей. Возможно, вы захотите увеличить свой innodb_buffer_pool_size, 128M может быть немного ниже, и даже небольшие сайты могут расти очень быстро. Переменная определяет, сколько ваших данных хранится в памяти.

Magento использует это для всех своих таблиц, включая таблицы журналов, которые быстро растут. Вы хотите убедиться, что вы ограничиваете количество этих данных, которые вы храните. Запуск "php shell / log.php --status" из командной строки даст вам представление о том, где вы находитесь, и если он выходит из-под контроля. Есть также варианты очистки таблиц журнала с ним.

С 2 ГБ ОЗУ не так много работы, поэтому вы должны быть осторожны с тем, куда вы распределяете свою память.

Кроме того, Full Page Cache + Cache Warmer может помочь быстро и быстро заполнить каталог и страницы cms вашего сайта. Вы можете увидеть наши здесь: http://ecommerce.brimllc.com/full-page-cache-magento.html