@Impeeeery
жуй. куй.

Как ускорить работу Apache: отдачу статических файлов и выполнение PHP?

Поможет ли переход на FastCGI с mod_php?

А вопрос вот к чему.
Есть сайт, раньше лежал на хостинге, переходим на VPS и стоит задача - сделать его хотя бы не медленнее, чем было.
На VPS даже более мощное железо - Intel Xeon 3.4 ГГц, против 2.2 на хостинге.
Ядра - там 4 и лимит нагрузки 25%, здесь 3 и лимита нет, это наши ядра)
Диск - SSD.
ОС - Ubuntu.
PHP - там 7.0.7 и у нас вроде тоже.
Но увы, работает гораздо медленнее, много времени именно от начала отдачи ответа до ее окончания, на всех запросах, включая основной GET html.

И ладно бы только страницы, но даже простой text/plain файл на хостинге отдается раза в 3 быстрее, хотя это именно первый запрос, а не Not Modified.
Вернее, на хостинге нестабильно, то быстрее, то медленнее, но это лучше, чем стабильная медлительность VPS.

Изучил весь httpd.conf, перекопал кучу гайдов по highload (они старые и с сомнительными советами типа "отключить лишние модули", хотя на хостинге судя по списку модулей в адмике явно этим не занимались, а также советами по куче параметров в httpd.conf, которые я вертел и так и сяк), попробовал pagespeed.
Ничего не помогло, pagespeed по факту мало помог даже для страниц (ну а для txt он и не должен помочь), хотя в Просмотре кода страницы выглядеть стало круче.

Ну, хорошо, успех хостинга со статикой объясняем CDN или еще каким кешем.
Еще можно приплести сюда интернет-канал.
Но вот еще один эксперимент: вставим в файл более трудоемкий PHP-код (не добавив ни байта к весу ответа) - и хостинг сразу уходит в отрыв крат на 10.
Явно проблема не в отсутствии CDN и не в интернет-канале, memcached тут не поможет, проблема именно в быстродействии связки Apache+PHP.

Вопросы:
1) Это у всех VPS так называемый "мощный" процессор медленнее, чем на каком-то жалком хостинге, пусть и с VIP-тарифом?
2) Поможет ли в такой ситуации FastCGI?
3) Почему не популярны фишки типа eAccelerator (кеширование AST и т.п.)?
Я знаю, что многие из них заброшены, но это не причина, а следствие.
4) Что еще может помочь?
  • Вопрос задан
  • 3883 просмотра
Пригласить эксперта
Ответы на вопрос 5
Wolfnsex
@Wolfnsex Куратор тега PHP
Если не хочешь быть первым - не вставай в очередь!
Изучил весь httpd.conf, перекопал кучу гайдов по highload (они старые и с сомнительными советами типа "отключить лишние модули"
Один из первых модулей, который стоит отключить у Apache'а, для скорости - это поддержку файлов .htaccess, сама эта поддержка производительности не добавляет, а наличие этих файлов - уж и подавно.

1) Это у всех VPS так называемый "мощный" процессор медленнее, чем на каком-то жалком хостинге, пусть и с VIP-тарифом?
Нет, возможно это у Вас, персонально, какой-то дрянной VPS-хостер, или того хуже, тариф аки "OpenVZ, мы не перепродаём проданные ресурсы... ну разве что раз 10, но больше не перепродаём"

2) Поможет ли в такой ситуации FastCGI?
FastCGI - это режим работы PHP, напрямую, на производительность в значительной степени он не влияет, более того, сама логика работы FCGI (если сравнивать Apache-FCGI и Apache-mod_php) будет медленнее, по тому как для взаимодействия FastCGI будет использоваться сокет ("обычный" или unix-сокет), что подразумевает сетевое взаимодействие, вместо непосредственной работы интерпретатора PHP "внутри" сервера. Думаю, Вам поможет несколько другое (постараюсь описать ниже).

3) Почему не популярны фишки типа eAccelerator (кеширование AST и т.п.)?
Понятия не имею, почему они не популярны и откуда у Вас такая статистика... Но, возможно, дело в том, что eAccelerator морально и физически устарел, и если верить например, вот такой банальной статье (нет, я не работаю с такой "шедевральной" CMS как "Битрикс", просто это первое упоминание про eAccelerator, которое пришло мне в голову) - с версиями PHP выше 5.3 не работает.

Я знаю, что многие из них заброшены, но это не причина, а следствие.
Не могу прокомментировать это, так как Вы не указали следствие - чего именно. Другими словами, я не совсем понимаю, что Вы хотели этим сказать.

4) Что еще может помочь?
Ну так, сходу, по памяти (варианты могут быть не связаны между собой):
1. Отказ от поддержки .htaccess в Apache или хотя бы сокращение их количества
2. Установка Nginx в качестве фронтального сервера, для отдачи статики
3. Полный отказ от Apache вообще и переход на Nginx+FCGI (только не подумайте, я очень люблю Apache за его гибкость в настройке и широкие возможности, другой вопрос, что мало кому эта гибкость фактически нужна и мало кто способен его грамотно, качественно и полноценно настроить... Nginx в этом плане будет куда попроще). Почему FCGI? По тому, что другой приемлемый способ взаимодействия Nginx'а с PHP мне не известен. Настройка FCGI-пула - обязательна.
4. OpCache - с версии 5.5 встроено "искаропки", к включению и настройке - настоятельно рекомендуется. Я не знаю, как обстоят дела с CMS и используете ли Вы CMS на сайте, но из моей практики, скорость работы PHP-фреймворков возрастает в среднем 8-20 раз.
5. HHVM, как альтернатива
6. Проверка:
а) Того, что дело действительно в PHP. В частности, стоит собрать все логи сервера, например, сколько длились запросы, в БД, их количество и так далее.
б) Проверка скорости работы дисковой подсистемы... Не буду "тыкать пальцем", но одно время я арендовал довольно большое кол-во VPS'ок у одного популярного хостера, и в какой-то момент, я заметил, что средняя скорость работы дисковой подсистемы - 1.4Кбайт/сек., при этом "отказы" (аки "невозможно записать блок") были примерно в 50% случаев... это продлилось не очень долго, но и через несколько месяцев, у этого же хостера, тарифы с "обычным HDD", почему-то обладали более быстрой дисковой подсистемой, нежели тарифы с "быстрыми SSD"... можно сделать выводы...
в) Проверить реальную скорость работы процессора, не редко она отличается от завяленной достаточно сильно.

P.S. Если Вы сформулируете вопрос(ы) более точно - я смогу дать более точные рекомендации, если конечно они Вам нужны :)

P.P.S. Есть вариант решения проблемы вообще "в лоб", самый наверное сложный и пожалуй самый производительный в ряде случаев. Это Varnish + тонкая настройка оного, позволяет выдавать большую часть страниц из кэша (оперативной памяти) за наносекунды, иногда позволяет обслуживать очень много тысяч запросов в минуту, при этом, это не просто кэширование кода или что-то подобное... это кэширование целиком страниц и/или ответов сервера. Среди прочего - позволяет "не трогать бэкенд вообще", т.е. при запросе страницы, может не быть ни обращений к БД, ни выполнения того же PHP (или любого другого) кода, на стороне сервера. Требует довольно тонкой настройки, не очень подходит для сайтов "на CMS", для сайтов на фреймворках - требует изначально корректного подхода к разработке и продумывания того, что и как будет/должно кэшироваться. При некорректном подходе - наиболее вероятный результат - работать будет, но не так быстро как хотелось бы, а часть сайта вообще может перестать нормально функционировать. Есть так же другие решения, но с учётом довольно общих формулировок вопроса - говорить о них довольно сложно.

Ах, да, забыл важную деталь... Почему "хостинги" используют Apache и не откажутся от него (совсем)? В большей степени по тому, что Apache позволяет делегировать часть настроек пользователю через .htaccess. При этом, для статики не редко стоит всё тот же Nginx, который, как Вы понимаете, подобным образом делегировать часть настроек пользователю не позволяет, в виду чего для этих задач не подходит и не "буксует" на этом (в отличии от Apache'а). В т.ч. и по этому, мы на 99% отказались от "хостингов" (по причине наличие Apache'а, и невозможности от него избавиться или самостоятельно настроить, и как следствие "тормозов" которые приходят вместе с подобным подходом).
Ответ написан
Stalker_RED
@Stalker_RED
nginx для отдачи статики, и как фронтенд перед аапчем. Можно также совсем отказаться от апача в пользу nginx+php-fpm.

Если нужен CDN - попробуйте Cloudflare, по крайней мере для части ресурсов.
Ответ написан
Sanasol
@Sanasol Куратор тега PHP
нельзя просто так взять и загуглить ошибку
opium
@opium
Просто люблю качественно работать
на дешевом впсе у меня зарезанный проц одно ядро на 1000 гигагерц, на хостинге у меня 8 ядер по 3.9 гигагерца, как говорится разница на лицо
нет мод пхп самый быстрый вариант для пхп
они супер популярны но в новых версиях пхп уже есть встроенный зенд оп кеш их заменяющий и они просто умерли
nginx ?
Ответ написан
Вы допустили типичную ошибку купили xeon и думаете что он в зависимости от своей стоимости будет так же быстрей работать.
И так что вам нужно
skylike с максимальной частотой, дада - ваше " эээ железо" обгонит обычный core i3 не говоря уже о нормальном i7
Аренда его выйдет дешевле, покупка тоже,а производительность будет куда как лучше.
И причина тут в тактовой частоте, апачь плохо паралелит процессы, а даже паралеля их он все-равно хит выполняет на 1 проце. В следствие чего скорость вашего ксеонао в 2Ghz и есть ваша пиковая скорость и 30 ядер тут ниче не решают, обычный офисный комп его уделает.
Все что вы множите получить с этого железа это большое количество параллельных запросов, при той же скорости.
Но как вы понимаете вам нужно не это 10-50 Тыс человек в день вполне себе тянет 1 проц I7
по сути вы не проконсультировавшись или купили или арендовали полный хлам не подходящий для веб приложений. В частности для сайтов.
да можно хоститься и на этом железе, и часть вещей на нем так же будет лучше работать, а вот средний хит провалится в жесткий унитаз.

Рекомендую.
Снять дидикейт, дабы это не так трудно.
варианты
hetzner - германия отличные тарифы, берем только ссд и только скайлайки пинт 50
https://chipcore.com/ - питер, пинг 5-10 любой из тарифов всяко будет пободрей.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы