Как я могу помешать Apache падать?
Несколько Домен (UCC) сертификат SSL являются более дешевыми, чем Подстановочный знак SSL, часто предлагаемый. Это только работает на 5 доменных изменений вместо бесконечного числа, которое предлагает Подстановочный знак, но это может быть достойно рассмотрения, если Ваши потребности просты.
Так или иначе Единственный сертификат SSL может обработать Ваши потребности. Только цена и будущая гибкость отличаются.
Magento и Платформа Зенда довольно тяжелы ЦП, как Вы заметили. Лучший способ избежать загрузки ЦП просто, но представляющий любое содержание только однажды, пока это не изменяется. Большинство частей Вашего каталога не изменяет это часто и часто только блок корзины на Вашей странице, или 'самые популярные объекты' блок являются единственными динамическими частями.
Я предложил бы поместить кэш Лака перед Apache. Это дает Вам высокоэффективное кэширование страницы, которое может серьезно разгрузить Ваш стек LAMP. Мы недавно пережили очень общедоступный запуск веб-сайта благодаря Лаку, и я был серьезно впечатлен скоростью и низкой загрузкой ЦП. Лак свободен, и достаточно гибок, чтобы кэшировать все страницы или кэш только относительно статические части и включать корзину динамично.
Однако Лак не будет кэшироваться очень на установке Magento по умолчанию, так как существует много динамического контента в расчете на пользователя, cookie, и т.д. модуль Magento, таких как 'PageCache, приводимый в действие Лаком', изменяет Magento для работы хорошо с Лаком. Это также обеспечивает конфигурационный файл Лака, который соответствует установке Magento. Эти два вместе делают для очень эффективной установки. Это - коммерческий модуль, но намного более доступный, чем более мощный сервер был бы.
Части Ваша разгрузка к CDN или Nginx не является Вашей настоящей проблемой, хотя это действительно помогает. Даже Apache может обработать множество статических запросов. Необходимо кэшировать материал, который прилагает усилия для генерации снова и снова, т.е. динамические части.
Я обычно устанавливаю MaxRequestsPerChild, чтобы быть в тысячах - обычно, примерно 10 000.
Вы говорите, что у Вас есть "рекомендуемый PHP, кэширующийся" - но Вам устанавливали APC? Наконец, сколько пользователи, Вы видите удар веб-сайта одновременно. Если у Вас будет расширенная статистика Apache, то Вы сможете видеть, сколько из процессов Apache находится на самом деле в Состоянии выполнения за один раз.
800 хитов файла APC в секунду и еще 200 пользовательских кэшей много. Если бы это - двойное или четырехъядерное, я ожидал бы, что это поддержит на высоком уровне хорошо все же. Если база данных действительно поддерживает на высоком уровне, то, получая более крупную машину - и больше центральных процессоров, может быть лучшая вещь для него, по крайней мере прямо сейчас.
Ваша средняя загрузка полностью слишком высока для двухъядерного VPS. 8 должен быть максимум.
Я имел хороший успех с использованием mod_pagespeed и событие MPM for Magento. Я был бы, рекомендуя переключающийся на использование события MPM и установку mod_pagespeed.
Больше информации о Событии MPM: событие Apache документация MPM
И mod_pagespeed: Код Google: mod_pagespeed
Если Вы продолжаете иметь проблемы загрузки даже после создания вышеупомянутых изменений, можно хотеть рассмотреть переключение на другое, лучше план VPS.
Поскольку Alister подсказывает, значение MaxRequestsPerChild 400 является нелепо низким.
Среднее число загрузки очень высоко - но 60k просмотры страницы в день не являются большим трафиком.
сколько процессов у Вас обычно есть служащие запросы?
Я не знаком с Magento, но похоже, что существует что-то не так с этой установкой. Я ожидал бы, что Вы могли получить значительно больше пропускной способности на более низком уровне загрузки.
Пойдите получают копию книги Steve Souders и читают его. Включите сжатие для всего исходящего содержимого HTML (статичный и динамичный). И удостоверьтесь, что у Вас есть хорошая конфигурация кэширования. Начните регистрировать %D в своем access_log файле и создайте некоторые инструменты для анализа данных / изоляция замедления. Подобный для MySQL.
Попробуйте mysqltuner.pl и посмотрите, отмечает ли он какие-либо проблемы.
При использовании VPS, Вы совместно используете ЦП. Я рекомендовал бы говорить хостом, чтобы переместить VPS в менее занятые аппаратные средства или пойти выделенные.
Из-за общего ЦП Ваши приложения не могут работать вовремя и продолжать быть поставленными в очередь, создавая более высокие запросы, которые будут обработаны и также издержки, которые идут с ним. В конечном счете существует условие, где Apache или php или mysql истратили бы свои собственные пределы и те проблемы причины.
Концевая строка. VPS является в основном совместно использованный ЦП. Ваш хост может помещать слишком много учетных записей VPS на тот же ЦП.
Если Вы хотите полностью использовать выделенный ЦП, любой просит лучший Сервер с меньшим количеством VPS, если возможный (перемещают хост, хотя это неприятно) или идут выделенные.
Вы могли также выбрать Amazon полностью и не взволновать по поводу nginx использование их подсистемы балансировки нагрузки, которая является несколькими щелчками для установки для всех серверов под их облаком.
/var/mail.../корневая папка является средствами оттенка его сбор большого количества электронных писем, которые обычно прибывают из Ваших приложений. Для, например, ошибочный сценарий PHP пытается послать электронное письмо, или все задания крона настроены, чтобы послать Вам по электронной почте состояние выполнений крона и вывода. Можно посмотреть в почте и видеть то, что имеет файл. Я предполагаю его сообщения об ошибках, таким образом, можно найти где его прибытие из.
Я добавлю больше, если Вы будете нуждаться в дальнейшей информации и сможете быть, то мне будет нужна некоторая информация также
Я выполняю подобную установку, но с nginx/php-fpm/apc (код операции и fast_backend/memcached (slow_backend). Я нахожу, что php самая большая проблема ресурса, вероятно, потому что магнето является или безумно большим или просто плохо кодирован. Более тщательно изучите на том, что точно ест ресурсы, это мог быть php как в моем случае?
В дополнение к тому, что пишут Martijn Heemels, существует модуль лака с открытым исходным кодом, который Вы могли попробовать. Проверьте http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/ и https://github.com/madalinoprea/magneto-varnish.
Я только протестировал его в тестовой среде, и пока неплохо.
Вы сохраняете сессии в базе данных, или на диске (и если так, на tmpfs)?