Боюсь представить, что было бы если б у меня был не пустячный вопрос, а реальные траблы с хостингом/впс.
Да и онлайн чат что-то не алё, вообще не вижу его на сайте. Или это только у меня что-то с браузером? Вроде был раньше. Кроме того, есть вопросы по партнерке, что-то странно она у вас работает.
Только так. Сначала на https, потом на www. Иначе будут циклически переадресации или еще какая-нибудь ерунда.
Единственное, можно написать редирект без привязки к домену, но это уже просто вопрос универсальности и красивостей. Работать оно будет точно так же как и ваш вариант
Andreyka: Сами себе придумали, что у апача тяжелые процессы, сами себя убедили в том, что php-fpm - панацея. А проблема может быть например в кривых запросах к mysql, где понатыкали select join distinct group by, который не оптимизируется а нуждается в полной замене + замене в коде. Оперативка кончается - начинаются проблемы из-за временных таблиц, которые пишутся в своп.
Ставите php-fpm и получаете экономию по памяти допустим 5%. Этого хватает, чтоб временные таблицы снова писались в оперативку на какое-то время и радуетесь:
- Ура! Производительность выросла в разы! Целебный php-fpm спас жизнь тяжело больного сервера!
Хотя у вас был просто временный эффект от высвобождения оперативки.
Просто попробуйте, зачем писать ерунду про 5% и кривые запросы под видом эксперта) Стандартные cms типа wp у десятков клиентов и на собственных серверах, сетки сайтов на известных CMS типа dle, wp. Rакие кривые запросы?) И нестандартные тоже - парсеры, самописные системы. Везде есть этот выигрыш в производительности и готовность к нагрузке. И не на 5%, а в 3-5 раз. Не временный, а с момента настройки и навсегда.
Stek: Вы путаете теплое с мягким. Апач выполняет скрипт и отдает результат. А вот fpm только выполняет скрипт, а результат отдает уже nginx. И именно за счет того, что результат отдает не тяжелый процесс апача, а легкий nginx - и достигается значительная экономия памяти вэб сервера. Что уменьшает возможный своп, а следовательно и дисковую нагрузку вкупе с процессорной.
Я-то это понимаю. Но в каком месте это идет вразрез с моими словами о том, что такая связка производительней и меньше ресурсов ест при одинаковой нагрузке?) То же самое и конечному клиенту - ему по барабану что-там внутри происходит, главное чтоб работало хорошо и быстро.
Я не спорю, можно и апач настроить чтоб работало нормально. Так можно и осла разогнать до 100 км/ч. Вопрос только один - зачем, если можно сесть в авто?) Чтобы держать такие нагрузки, как выше я показал на графиках (100 юзеров в секунду) - понадобятся мощные дедики с кучей ядер и десятками Gb RAM. А эта связка спокойно выдерживает подобное на минимальном VPS за 5 баксов :)
Stek: Вообще то это совершенно две разные вещи. Одно вэб сервер, а другое виртуальная машина для выполнения пхп кода. У них совершенно разное назначение.
Вот именно в этом и недостаток апача. Он может все, но делает это хуже и с большими затратами ресурсов, чем узко-заточенные решения вроде HHVM или того же php-fpm.
Andreyka: Stek, это бесполезно. Просто redeyer свято верит в php-fpm, оставьте его в покое.
Это так :) Но это не фанатичность, а прагматизм. Просто берем и юзаем. Там работает так. Тут сяк. Тут не надо никакой веры, все очевидно.
Не понимаю почему люди спорят с наглядными и очевидными фактами, взятыми из практики :) Покажите мне обратное, что апач держит лучше :) Зачем все эти притянутые за уши рассуждения о теплом и мягком ?)
А то темы начинаются с того что апач не держит, а как начинаешь говорить где выход - так сразу активизируются холиварщики что апач это вообще едва ли не лучшее, что случалось в IT )
Ventor: Поэтому я тестирую на максимальные нагрузки во всем.
Мой вам совет - запускайте проекты и решайте вопросы по мере их поступления :) Пойдет реальная нагрузка - тогда и надо искать решения и оптимизировать.
Тестов нет, но есть десятки клиентов, и сотни серверов, на которых всё наблюдалось и настраивалось. Я говорю основываясь именно на практическом опыте, а не на тестах. Тесты тоже делались и много. Даже HP как-то тестировали на нагрузку систему, которую я настраивал :) Но очень давно, и результатов их, конечно, нет под рукой.
Зато есть кейс по оптимизации VPS под нагрузку, в котором очень наглядно и отчетливо видно, что происходит с использованием ресурсов сервера после переключения в режим nginx+php-fpm:
Вот еще график, клиент прислал, дорвейщик.
Вот, дорвейщикам, кстати, очень помогает это. Среди клиентов есть ребята. У них обычно мощные дедики, с сотнями сайтов и парсерами. После подобной оптимизации сервак "дышать" начинает.
Поэтому, тесты тестами, а апач НЕ НУЖЕН ☝
Возможно для разработки хорошо, удобно - поставил и оно работает.
Но там где нагрузки... да скажите мне, нахрена фейсбук пилил свой HHVM, если апач настолько хорош?
UPD
Stek: Смысл нджинса в том, что бы избавиться от тяжелых процессов апача.
Да ладно? Это какие же тяжелые процессы на себя берет nginx, если он не может обрабатывать php? Nginx берет на себя статику, а апач все так же продолжает пыхтеть под обработкой php, как и без него.
Stek:
Производительность будет та же самая. php-fpm - это просто другой вариант запуска php интерпритатора, не более.
Да как вам угодно) Я вижу результаты. И просто показываю графики. Апач работает очень туго, по сравнению с php-fpm.
Небольшой сайт с трафиком, под развитие. Wordpress c парсером ютуба. Детская тематика, видео, мультики. Очень дешево, отстоявшийся домен. Отлично подойдет как стартовая площадка для СДЛ по теме.
Stek: Обычно для быстрого решения просто ставиться nginx в качестве прокси сервера перед apache .
В базовом виде, как это используют хостеры - это ровным счетом ничего не дает к улучшению производительности. Начинает "лучше" отдавать статику. Апач при отдаче статики немногим хуже nginx. Так что здесь выгода едва ли.
Nginx просто будет всегда отвечать, какой бы нагрузки там не было - он не упадет, в отличие от "чистого" apache.
В связке nginx+apache - это как если бы шасси у вас от гоночного болида было, а двигатель от трактора "Беларусь".
Stek: Или вообще переводится на голый nginx.
Не совсем голый, а на связку nginx+php-fpm. php-fpm в качестве бэкенда в 3-5 раз производительней апача по выдерживаемой нагрузке, при этом раза в 2-3 меньше ресурсов потребляет. VPS минимального тарифа у любого хостера будет спокойно выдерживать 20-30к суточного трафа (пруф на кейс переключения c apache на php-fpm), а если настроить кэширование в nginx (что это и как? ), то еще больше.
Что касается debian и centos - разницы особой нет, дефолтный апач что-там что тут нормально работает, и не способен выдерживать нагрузки. Опять же, кэширование может позволить выдерживать нагрузки, но если у вас сервис, или интернет-магазин - то его использовать надо с осторожностью и вообще не рекомендуется.
Ventor: Я начал расспрашивать свою техподдержку, мол на центосе плохо работает phpbb, с одновременно (в одну секунду) более 15 юзеров.
А вам под какую нагрузку нужно и какого результата хотите добиться?
Я зарегился в этом loader.io, запустил пару тестов на свой сайт на wordpress. Он настроен на nginx+php-fpm и включено кэширование в nginx.
Вот так примерно выглядит работа моего сайта при нагрузке в 15 юзеров в секунду:
У меня минимальный VPS у hetzner. Получилось 0,4 секунды среднее время ответа при такой нагрузке.
Для интереса попробовал нагрузить в 100 юзеров в секунду. Среднее время ответа - около 2 секунд.
И появилось около 3 процентов ошибок сети. Сетевой стек у меня на vps настроен по-умолчанию, поэтому так.
Но это чистейшая синтетика, в этих тестах мало смысла. Во-первых, потому что такая нагрузка на практике возможна только у гугла и всяких фейсбуков. Даже 15 юзеров в секунду - это дикая посещаемость в миллионы хостов в сутки. Не говоря уже о 100 юзерах в секунду :)
Во-вторых, эти тесты не показывают реальной нагрузки, потому что они просто долбятся в одну страницу. Там сама ОС и серверный софт справляется с подобной топорной нагрузкой в десятки раз лучше, чем если бы это было при 15 юзерах в секунду реальной нагрузки.
Поэтому тестируйте юзера 3 в секунду, это более адекватно и для подобных ресурсов и для апача :)
Что в итоге ограничит полосу пропускания до 0,5мбит/сек на каждое соединение, а количество соединений до одного на каждый клиентский IP. Со вторым следует аккуратней, ибо рискуете блокировать каких-то клиентов, подключающихся с одного IP. Я бы не стал использовать ограничение на количество коннектов.
Не пойму почему вопрос стоит именно так. Если у вас проблема в сомнительности работы провайдера, то надо просто сменить провайдера. Вопрос об отказоустойчивости как-то бессмысленно ставить, если дело в нестабильности подключения. Какой-то dyndns надо выдумывать. Обычно в отказоустойчивость делают когда в разных ДЦ дублируют серверы, получается кластер.
Ну и потом, round-robin - это круговой опрос серверов за А-записью, насколько я знаю, поэтому оно тоже должно решать проблему, если один из серверов лег. Никакой трафик не должен при этом теряться. Именно так работают крупнейшие соцсети, и сервисы:
Чет с тикетами совсем тухловато у вас:
Боюсь представить, что было бы если б у меня был не пустячный вопрос, а реальные траблы с хостингом/впс.
Да и онлайн чат что-то не алё, вообще не вижу его на сайте. Или это только у меня что-то с браузером? Вроде был раньше. Кроме того, есть вопросы по партнерке, что-то странно она у вас работает.
Только так. Сначала на https, потом на www. Иначе будут циклически переадресации или еще какая-нибудь ерунда.
Единственное, можно написать редирект без привязки к домену, но это уже просто вопрос универсальности и красивостей. Работать оно будет точно так же как и ваш вариант
Сами себе придумали, что у апача тяжелые процессы, сами себя убедили в том, что php-fpm - панацея. А проблема может быть например в кривых запросах к mysql, где понатыкали select join distinct group by, который не оптимизируется а нуждается в полной замене + замене в коде. Оперативка кончается - начинаются проблемы из-за временных таблиц, которые пишутся в своп.
Ставите php-fpm и получаете экономию по памяти допустим 5%. Этого хватает, чтоб временные таблицы снова писались в оперативку на какое-то время и радуетесь:
- Ура! Производительность выросла в разы! Целебный php-fpm спас жизнь тяжело больного сервера!
Хотя у вас был просто временный эффект от высвобождения оперативки.
Просто попробуйте, зачем писать ерунду про 5% и кривые запросы под видом эксперта) Стандартные cms типа wp у десятков клиентов и на собственных серверах, сетки сайтов на известных CMS типа dle, wp. Rакие кривые запросы?) И нестандартные тоже - парсеры, самописные системы. Везде есть этот выигрыш в производительности и готовность к нагрузке. И не на 5%, а в 3-5 раз. Не временный, а с момента настройки и навсегда.
Вы путаете теплое с мягким. Апач выполняет скрипт и отдает результат. А вот fpm только выполняет скрипт, а результат отдает уже nginx.
И именно за счет того, что результат отдает не тяжелый процесс апача, а легкий nginx - и достигается значительная экономия памяти вэб сервера. Что уменьшает возможный своп, а следовательно и дисковую нагрузку вкупе с процессорной.
Я-то это понимаю. Но в каком месте это идет вразрез с моими словами о том, что такая связка производительней и меньше ресурсов ест при одинаковой нагрузке?) То же самое и конечному клиенту - ему по барабану что-там внутри происходит, главное чтоб работало хорошо и быстро.
Я не спорю, можно и апач настроить чтоб работало нормально. Так можно и осла разогнать до 100 км/ч. Вопрос только один - зачем, если можно сесть в авто?) Чтобы держать такие нагрузки, как выше я показал на графиках (100 юзеров в секунду) - понадобятся мощные дедики с кучей ядер и десятками Gb RAM. А эта связка спокойно выдерживает подобное на минимальном VPS за 5 баксов :)
Вообще то это совершенно две разные вещи. Одно вэб сервер, а другое виртуальная машина для выполнения пхп кода. У них совершенно разное назначение.
Вот именно в этом и недостаток апача. Он может все, но делает это хуже и с большими затратами ресурсов, чем узко-заточенные решения вроде HHVM или того же php-fpm.
Stek, это бесполезно. Просто redeyer свято верит в php-fpm, оставьте его в покое.
Это так :) Но это не фанатичность, а прагматизм. Просто берем и юзаем. Там работает так. Тут сяк. Тут не надо никакой веры, все очевидно.
Не понимаю почему люди спорят с наглядными и очевидными фактами, взятыми из практики :) Покажите мне обратное, что апач держит лучше :) Зачем все эти притянутые за уши рассуждения о теплом и мягком ?)
А то темы начинаются с того что апач не держит, а как начинаешь говорить где выход - так сразу активизируются холиварщики что апач это вообще едва ли не лучшее, что случалось в IT )
Поэтому я тестирую на максимальные нагрузки во всем.
Мой вам совет - запускайте проекты и решайте вопросы по мере их поступления :) Пойдет реальная нагрузка - тогда и надо искать решения и оптимизировать.
Результатты Ваших тестов показать можете? Например:
nginx+php-fpm vs apache+mod_php
nginx+php-fpm vs uWSGI
Это отнюдь не сарказм, мне действительно было бы очень интересно увидеть результатты таких тестов. Естественно, не в дефолтной конфигурации апача :).
А то люди, которые не поленились выполнить хоть какие-то тесты, обычно, не столь категоричны, например:
http://slonik-v-domene.livejournal.com/141951.html
---
Виктор
Тестов нет, но есть десятки клиентов, и сотни серверов, на которых всё наблюдалось и настраивалось. Я говорю основываясь именно на практическом опыте, а не на тестах. Тесты тоже делались и много. Даже HP как-то тестировали на нагрузку систему, которую я настраивал :) Но очень давно, и результатов их, конечно, нет под рукой.
Зато есть кейс по оптимизации VPS под нагрузку, в котором очень наглядно и отчетливо видно, что происходит с использованием ресурсов сервера после переключения в режим nginx+php-fpm:
Вот еще график, клиент прислал, дорвейщик.
Вот, дорвейщикам, кстати, очень помогает это. Среди клиентов есть ребята. У них обычно мощные дедики, с сотнями сайтов и парсерами. После подобной оптимизации сервак "дышать" начинает.
Поэтому, тесты тестами, а апач НЕ НУЖЕН ☝
Возможно для разработки хорошо, удобно - поставил и оно работает.
Но там где нагрузки... да скажите мне, нахрена фейсбук пилил свой HHVM, если апач настолько хорош?
UPD
Смысл нджинса в том, что бы избавиться от тяжелых процессов апача.
Да ладно? Это какие же тяжелые процессы на себя берет nginx, если он не может обрабатывать php? Nginx берет на себя статику, а апач все так же продолжает пыхтеть под обработкой php, как и без него.
Производительность будет та же самая. php-fpm - это просто другой вариант запуска php интерпритатора, не более.
Да как вам угодно) Я вижу результаты. И просто показываю графики. Апач работает очень туго, по сравнению с php-fpm.
Небольшой сайт с трафиком, под развитие. Wordpress c парсером ютуба. Детская тематика, видео, мультики. Очень дешево, отстоявшийся домен. Отлично подойдет как стартовая площадка для СДЛ по теме.
http://www.telderi.ru/ru/viewsite/1006544
Обычно для быстрого решения просто ставиться nginx в качестве прокси сервера перед apache .
В базовом виде, как это используют хостеры - это ровным счетом ничего не дает к улучшению производительности. Начинает "лучше" отдавать статику. Апач при отдаче статики немногим хуже nginx. Так что здесь выгода едва ли.
Nginx просто будет всегда отвечать, какой бы нагрузки там не было - он не упадет, в отличие от "чистого" apache.
В связке nginx+apache - это как если бы шасси у вас от гоночного болида было, а двигатель от трактора "Беларусь".
Или вообще переводится на голый nginx.
Не совсем голый, а на связку nginx+php-fpm. php-fpm в качестве бэкенда в 3-5 раз производительней апача по выдерживаемой нагрузке, при этом раза в 2-3 меньше ресурсов потребляет. VPS минимального тарифа у любого хостера будет спокойно выдерживать 20-30к суточного трафа (пруф на кейс переключения c apache на php-fpm), а если настроить кэширование в nginx (что это и как? ), то еще больше.
Что касается debian и centos - разницы особой нет, дефолтный апач что-там что тут нормально работает, и не способен выдерживать нагрузки. Опять же, кэширование может позволить выдерживать нагрузки, но если у вас сервис, или интернет-магазин - то его использовать надо с осторожностью и вообще не рекомендуется.
Я начал расспрашивать свою техподдержку, мол на центосе плохо работает phpbb, с одновременно (в одну секунду) более 15 юзеров.
А вам под какую нагрузку нужно и какого результата хотите добиться?
Я зарегился в этом loader.io, запустил пару тестов на свой сайт на wordpress. Он настроен на nginx+php-fpm и включено кэширование в nginx.
Вот так примерно выглядит работа моего сайта при нагрузке в 15 юзеров в секунду:
У меня минимальный VPS у hetzner. Получилось 0,4 секунды среднее время ответа при такой нагрузке.
Для интереса попробовал нагрузить в 100 юзеров в секунду. Среднее время ответа - около 2 секунд.
И появилось около 3 процентов ошибок сети. Сетевой стек у меня на vps настроен по-умолчанию, поэтому так.
Но это чистейшая синтетика, в этих тестах мало смысла. Во-первых, потому что такая нагрузка на практике возможна только у гугла и всяких фейсбуков. Даже 15 юзеров в секунду - это дикая посещаемость в миллионы хостов в сутки. Не говоря уже о 100 юзерах в секунду :)
Во-вторых, эти тесты не показывают реальной нагрузки, потому что они просто долбятся в одну страницу. Там сама ОС и серверный софт справляется с подобной топорной нагрузкой в десятки раз лучше, чем если бы это было при 15 юзерах в секунду реальной нагрузки.
Поэтому тестируйте юзера 3 в секунду, это более адекватно и для подобных ресурсов и для апача :)
Как выключаю nginx - видео подгружается моментально..
я не знаю в чем там может быть дело, но nginx наоборот должен отдавать файлы гораздо быстрей. Возможно проблема в проигрывателе.
пошагово:
Эту строчку добавить в /etc/nginx.conf, в контекст http:
А такой фрагмент в конфиг нужного сайта, в контекст server:
Что в итоге ограничит полосу пропускания до 0,5мбит/сек на каждое соединение, а количество соединений до одного на каждый клиентский IP. Со вторым следует аккуратней, ибо рискуете блокировать каких-то клиентов, подключающихся с одного IP. Я бы не стал использовать ограничение на количество коннектов.
Не пойму почему вопрос стоит именно так. Если у вас проблема в сомнительности работы провайдера, то надо просто сменить провайдера. Вопрос об отказоустойчивости как-то бессмысленно ставить, если дело в нестабильности подключения. Какой-то dyndns надо выдумывать. Обычно в отказоустойчивость делают когда в разных ДЦ дублируют серверы, получается кластер.
Ну и потом, round-robin - это круговой опрос серверов за А-записью, насколько я знаю, поэтому оно тоже должно решать проблему, если один из серверов лег. Никакой трафик не должен при этом теряться. Именно так работают крупнейшие соцсети, и сервисы: