Очень беспокоюсь о производительности Magento

Question

я в настоящее время 1 Magento приложение работает 3 различных магазинов:

• BelExpress
• Medical em Casa
• Medical Express (это один еще находится в стадии строительства)

базе данных для этого магазина 370MB в размере. В магазинах используется 9000 SKU, и они имеют от 1 до 2 тысяч сгруппированных продуктов (которые ассоциируют SKU).

Запуск тестового инструмента apache AB, я нахожу всего 0,29 запросов в секунду, что, по моему мнению, очень мало, даже для магазина magento.

Самое большое беспокойство, однако, является основой. В настоящее время 5 человек обновляют и вставляют новые продукты через бэкэнд, и для обновления/вставки ОДНОГО продукта требуется 4 минуты. Это огромная трата времени, и я не могу объяснить, как это объясняется мне.

Вот ресурсы моего сервера:

• Процессор: AMD Athlon X2 3400+ (2x 1.8Ghz)
• Память: 4 Гб
• Диски: 2x 500Gb

Я запуск Debian Lenny Apache 2.0, PHP версии 5.2.6-1 + lenny16 с eAccelerator и Memcahed. (вы можете проверить всю информацию here)

И вот мои конфигурационные файлы для Apache, MySQL и PHP.

• Apache
• MySQL
• PHP

Я не администратор сервера (хотя я ответственен за все веб-сайты и сам сервер), так что это не мой «пляж " так сказать. Мой вопрос в том, как это должно работать с моими текущими ресурсами, или я пропускаю что-то важное в моей конфигурации?

Я понимаю, это может показаться, что я ищу «руку», но это не мое намерение. Я просто устал пробовать новый материал снова и снова, и я просто не могу заставить его работать гладко.

Answer 1

Простой ответ: сервер недофинансирован. Независимо от того, как вы это настроите, вам нужно будет обновить среду, более подходящую для Magento.

Источник: http://www.cpubenchmark.net/cpu.php?cpu=AMD+Athlon+64+X2+Dual+Core+3400%2B

Имейте в виду, хотя, процессоры, перечисленные выше, являются очень высокого класса процессоры с примерно в 10 раз больше вычислительной мощности по сравнению с двухъядерным чипом AMD. Мой ноутбук, который является четырехъядерным процессором Intel Core i7 2.2GHz, составляет около 5000. Я бы порекомендовал вам перейти на процессор выше 5000 из list found here.

ОЗУ 16 ГБ и SSD также выглядят разумно/разумно, учитывая, что в наши дни это не так дорого.

Answer 2

Magento требует много ресурсов. Бэкэнд-структура - это что-то вроде медленного и трудного для оптимизации. Но я предлагаю импортировать весь продукт из csv/xml и не делать это вручную. Вы найдете много учебников по этому вопросу.

Чтобы оптимизировать внешний интерфейс, вот несколько советов:

• Обратитесь к GTMetrix, чтобы показатели вашей производительности: http://gtmetrix.com/reports/www.belexpress.eu/k2bPETVr стартовой слишком большой. При первой загрузке страница не должна превышать 1 МБ. Вы должны использовать ленивую загрузку, оптимизировать изображение и т. Д., Чтобы ускорить это.

• Некоторые советы позволяют иметь очень высокую производительность, но вам нужен более крупный сервер, если ваш сайт генерирует трафик, и вы можете получить 500 долларов в месяц за хостинг, вы можете найти очень мощную конфигурацию сервера, такую ​​как 6 Quad Core, 48 ГБ оперативной памяти, SSD-диски, сеть 10 ГБ/с с неограниченной пропускной способностью.

• Если вы выбрали лучшее решение для хостинга (с более мощным сервером), вы можете получить производительность, установив в качестве ОЗУ наиболее используемые каталоги, такие как/var и/include/src, если вы используете компиляцию. Используйте компиляцию только в том случае, если вы не вносите ежедневные изменения в свой код, если вы этого не сделаете, компиляция + установка/включение/src, поскольку оперативная память даст вам очень хорошую производительность.

• Не знаю хорошо eAccelerator и memcached, personnaly Я использую APC, и я заменил порт 80 лаком. Это дает дополнительную скорость моим сайтам.

Имея Magento быстро, это ежедневная работа по оптимизации всех аспектов, нет никаких фокусов.

С уважением,

Answer 3

Вашего размером кэша является слишком низким для сайта, как Magento. Я запускаю аналогичный сайт, и у нас 256 МБ кеша. С 16mb вы будете постоянно работать в кэшировании свалок.

Ваши серверные ресурсы подходят для вашей загрузки, предполагая, что рядом с Magento не будет ничего огромного. Это свиньи, но это не так уж плохо, и 4 ГБ ОЗУ более чем достаточно.

Я бы временно отключил кеш и посмотрел, улучшает ли это что-либо. Я также рекомендую вам просмотреть конфигурацию магазина в Magento, потому что у вас может не быть лучшей конфигурации кэширования. Настройка кэширования Magento сложна и непрозрачна.

Answer 4

Я занимаюсь разработкой веб-сайтов для компании, которая обрабатывает продукты 30k + на 7 сайтах, и мы обычно стараемся избегать использования admin для загрузки/редактирования продуктов. Мы используем magmi для загрузки и редактирования. Мы очень довольны этим продуктом. Вы используете сервер ligtspeed?

Answer 5

Если вы сделали с развитием, я бы отключить ведение журнала медленно запросов на MySQL (строки копируются из вашего my.cnf):

log_slow_queries  = /var/log/mysql/mysql-slow.log 
long_query_time = 2 

Вы не отправлял файл .htaccess, где некоторые PHP и Настройки apache можно переопределить.

Добавили ли вы настройки кеша в свой /app/etc/local.xml? Если нет, посмотрите /app/etc/local.xml.additional и примените то, что вам больше всего подходит.

Answer 6

Если вы используете виртуальный сервер, возможно, посмотрите на использование Nginx в качестве замены Apache. Я нашел, что это может дать некоторые повышения производительности. Также обратите внимание на реализацию какого-то кеширования. Я бы рекомендовал использовать Memcached или Redis (если вы можете запустить его). Это, несомненно, даст вам большой прирост производительности.

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

Answer 7

Я знаю, что эта тема является древним интернет-временем. Просто подумал, что добавлю несколько моментов, которые, по моему мнению, наиболее актуальны для большинства владельцев/разработчиков. производительность Magento может быть глубокая тема со многими вещами toconsider, но мы надеемся понять несколько основных моментов будет пройти долгий путь:

1. Чем больше вы кэширование рычагов (кэш опкод, кэш MySQL, полный кэш страниц и т.д. .) тем менее важным является hardwar e. Звучит здорово, потому что аппаратное обеспечение, на котором вы сейчас находитесь, к сожалению, довольно ужасно (как уже указывалось). Вы можете обойти это и создать маску проблем с производительностью, улучшив кэширование. Самое главное - настроить кеш полной страницы (google) и кеш-код операции.
2. В то время как кэширование поможет ускорить работу, плохое аппаратное обеспечение будет заметным, если вы нажмете не кэшированные страницы, как страницы с отфильтрованной категорией, поисковые страницы, тележку, выписку и т. Д. В принципе ничего уникального. Когда посетитель попадает на одну из этих страниц, большинство ваших cahces обходят, а затем сводятся к хорошей настройке оборудования/хорошо настроенной. На этом этапе будет очевидно, что есть проблемы с производительностью.
3. В общем, более быстрый процессор (более высокий ГГц) будет означать, что многие PHP-файлы, содержащие Magento (примерно 14 000+), могут быть обработаны быстрее. PHP почти всегда является самым большим узким местом.
4. SSDs поможет немного из-за более низкой задержки, но они действительно помогают с более крупными каталогами (больше продуктов или заказов в системе). В этом случае SSD, как правило, превосходит HDD (даже 15 000 об/мин), поскольку данные распределяются по большему разделу на диске, поэтому он должен подпрыгивать в разных физических местах на жестком диске для доступа к различным таблицам MySQL и доступа к данным , SSD обрабатывают этот вид «случайного поиска» намного лучше. Если у вас достаточно памяти для загрузки всей вашей БД в память, это не имеет большого значения, кроме как при написании заказа для базы данных во время проверки или данных о продукте для сохраненной корзины и т. Д.
5. Распространенным заблуждением является то, что больше CPU cores = быстрее сайт. Это очень вводит в заблуждение. Подумайте о процессоре, как о большой автостраде. Ядра подобны полосам на автостраде, а CPU GHz - как ограничение скорости. Вы бы предпочли иметь 20 полос шириной 50 миль в час или 1 полосу со скоростью 100 миль в час? Зависит от количества трафика, правильно! Более одновременные посетители на вашем сайте означают, что в большинстве случаев будет больше ядер. Если у вас относительно низкий трафик, то меньше ядер, но более высокая тактовая частота намного лучше. Примите во внимание, что такие вещи, как Magento cron, indexer и администраторы, работающие в области администрирования, все добавляют к нагрузке. Если вы также добавили программы кэширования, такие как redis, memcache, лак и т. Д., Они также потребляют некоторое пространство на автостраде.
6. Простой способ проверить, не перегружен ли ваш процессор или жесткий диск, - проверить статистику сервера.Попробуйте установить что-то вроде sar, которое будет записывать статистику cpu/disk каждые 10 минут, чтобы вы могли просмотреть (можете настроить). Вы захотите увидеть% простоя процессора. Больше времени простоя = не работает слишком сложно. Наверное, не нужно больше ядер. Для диска проверьте столбец iowait (или используйте iostat в режиме реального времени). Если у вас высокий iowait, то, возможно, лучше диски или SSD помогут.
7. Чем больше у вас барана, тем больше вы можете кэшировать (и соединения, которые вы можете обрабатывать). Определенное количество бара используется для каждого подключения пользователей (apache/nginx/mysql) и для общих служебных издержек системы. Чем больше у вас барана, тем больше вы можете кэшировать в ram, который быстрее. Например, вы можете настроить MySQL и хранить большую часть данных в памяти, чтобы ускорить поиск вещей. Это связано с тем, что барабан не только имеет более низкую задержку, но также требует меньше циклов ЦП для извлечения данных. Результатом являются более быстрые нагрузки (иногда только незначительно) и значительно меньшая загрузка процессора. Вы можете хранить сеансы, кеш Magento, полные страницы cahces, данные MySQL и другие элементы в памяти. Таким образом, количество, которое вам нужно, может варьироваться, но вот общее правило: размер вашей базы данных должен составлять примерно 25-50% вашей памяти. Если у вас есть 1-граммовая пурпурная база данных, у вас должно быть около 4 ГБ памяти. Это, очевидно, изменяет больше сеансов или кешированных страниц и т. Д., Которые вы храните в памяти.
8. Часто CDN не оказывает существенного влияния на загрузку пользовательских страниц, но, что более важно, снижает нагрузку на сервер. Главным преимуществом CDN является то, что его серверы физически ближе к вашему посетителю для загрузки контента. Рассматривая более близкий сервер, он может только сбрить 50 мс с момента загрузки, но это не так сильно. Что еще более важно, имея дескриптор CDN, все требования для статических файлов могут оставить ваш сервер в основном для работы с динамическими запросами. В некоторых случаях это означает, что CDN обрабатывает загрузку для 90-99% активов, загружаемых на страницу (изображения, css, js и т. Д.). Под шипами трафика/высокими нагрузками, которые могут быть значительными.