Чет с тикетами совсем тухловато у вас:
Боюсь представить, что было бы если б у меня был не пустячный вопрос, а реальные траблы с хостингом/впс.
Да и онлайн чат что-то не алё, вообще не вижу его на сайте. Или это только у меня что-то с браузером? Вроде был раньше. Кроме того, есть вопросы по партнерке, что-то странно она у вас работает.
Только так. Сначала на https, потом на www. Иначе будут циклически переадресации или еще какая-нибудь ерунда.
Единственное, можно написать редирект без привязки к домену, но это уже просто вопрос универсальности и красивостей. Работать оно будет точно так же как и ваш вариант
RewriteCond %{HTTPS} offRewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]RewriteCond %{HTTP_HOST} !^www\.RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Просто попробуйте, зачем писать ерунду про 5% и кривые запросы под видом эксперта) Стандартные cms типа wp у десятков клиентов и на собственных серверах, сетки сайтов на известных CMS типа dle, wp. Rакие кривые запросы?) И нестандартные тоже - парсеры, самописные системы. Везде есть этот выигрыш в производительности и готовность к нагрузке. И не на 5%, а в 3-5 раз. Не временный, а с момента настройки и навсегда.
Я-то это понимаю. Но в каком месте это идет вразрез с моими словами о том, что такая связка производительней и меньше ресурсов ест при одинаковой нагрузке?) То же самое и конечному клиенту - ему по барабану что-там внутри происходит, главное чтоб работало хорошо и быстро.
Я не спорю, можно и апач настроить чтоб работало нормально. Так можно и осла разогнать до 100 км/ч. Вопрос только один - зачем, если можно сесть в авто?) Чтобы держать такие нагрузки, как выше я показал на графиках (100 юзеров в секунду) - понадобятся мощные дедики с кучей ядер и десятками Gb RAM. А эта связка спокойно выдерживает подобное на минимальном VPS за 5 баксов :)
Вот именно в этом и недостаток апача. Он может все, но делает это хуже и с большими затратами ресурсов, чем узко-заточенные решения вроде HHVM или того же php-fpm.
Это так :) Но это не фанатичность, а прагматизм. Просто берем и юзаем. Там работает так. Тут сяк. Тут не надо никакой веры, все очевидно.
Не понимаю почему люди спорят с наглядными и очевидными фактами, взятыми из практики :) Покажите мне обратное, что апач держит лучше :) Зачем все эти притянутые за уши рассуждения о теплом и мягком ?)
А то темы начинаются с того что апач не держит, а как начинаешь говорить где выход - так сразу активизируются холиварщики что апач это вообще едва ли не лучшее, что случалось в IT )
Мой вам совет - запускайте проекты и решайте вопросы по мере их поступления :) Пойдет реальная нагрузка - тогда и надо искать решения и оптимизировать.
Тестов нет, но есть десятки клиентов, и сотни серверов, на которых всё наблюдалось и настраивалось. Я говорю основываясь именно на практическом опыте, а не на тестах. Тесты тоже делались и много. Даже HP как-то тестировали на нагрузку систему, которую я настраивал :) Но очень давно, и результатов их, конечно, нет под рукой.
Зато есть кейс по оптимизации VPS под нагрузку, в котором очень наглядно и отчетливо видно, что происходит с использованием ресурсов сервера после переключения в режим nginx+php-fpm:
Вот еще график, клиент прислал, дорвейщик.
Вот, дорвейщикам, кстати, очень помогает это. Среди клиентов есть ребята. У них обычно мощные дедики, с сотнями сайтов и парсерами. После подобной оптимизации сервак "дышать" начинает.
Поэтому, тесты тестами, а апач НЕ НУЖЕН ☝
Возможно для разработки хорошо, удобно - поставил и оно работает.
Но там где нагрузки... да скажите мне, нахрена фейсбук пилил свой HHVM, если апач настолько хорош?
UPD
Да ладно? Это какие же тяжелые процессы на себя берет nginx, если он не может обрабатывать php? Nginx берет на себя статику, а апач все так же продолжает пыхтеть под обработкой php, как и без него.
Да как вам угодно) Я вижу результаты. И просто показываю графики. Апач работает очень туго, по сравнению с php-fpm.
Небольшой сайт с трафиком, под развитие. Wordpress c парсером ютуба. Детская тематика, видео, мультики. Очень дешево, отстоявшийся домен. Отлично подойдет как стартовая площадка для СДЛ по теме.
http://www.telderi.ru/ru/viewsite/1006544
В базовом виде, как это используют хостеры - это ровным счетом ничего не дает к улучшению производительности. Начинает "лучше" отдавать статику. Апач при отдаче статики немногим хуже nginx. Так что здесь выгода едва ли.
Nginx просто будет всегда отвечать, какой бы нагрузки там не было - он не упадет, в отличие от "чистого" apache.
В связке nginx+apache - это как если бы шасси у вас от гоночного болида было, а двигатель от трактора "Беларусь".
Не совсем голый, а на связку nginx+php-fpm. php-fpm в качестве бэкенда в 3-5 раз производительней апача по выдерживаемой нагрузке, при этом раза в 2-3 меньше ресурсов потребляет. VPS минимального тарифа у любого хостера будет спокойно выдерживать 20-30к суточного трафа (пруф на кейс переключения c apache на php-fpm), а если настроить кэширование в nginx (что это и как? ), то еще больше.
Что касается debian и centos - разницы особой нет, дефолтный апач что-там что тут нормально работает, и не способен выдерживать нагрузки. Опять же, кэширование может позволить выдерживать нагрузки, но если у вас сервис, или интернет-магазин - то его использовать надо с осторожностью и вообще не рекомендуется.
А вам под какую нагрузку нужно и какого результата хотите добиться?
Я зарегился в этом loader.io, запустил пару тестов на свой сайт на wordpress. Он настроен на nginx+php-fpm и включено кэширование в nginx.
Вот так примерно выглядит работа моего сайта при нагрузке в 15 юзеров в секунду:
У меня минимальный VPS у hetzner. Получилось 0,4 секунды среднее время ответа при такой нагрузке.
Для интереса попробовал нагрузить в 100 юзеров в секунду. Среднее время ответа - около 2 секунд.
И появилось около 3 процентов ошибок сети. Сетевой стек у меня на vps настроен по-умолчанию, поэтому так.
Но это чистейшая синтетика, в этих тестах мало смысла. Во-первых, потому что такая нагрузка на практике возможна только у гугла и всяких фейсбуков. Даже 15 юзеров в секунду - это дикая посещаемость в миллионы хостов в сутки. Не говоря уже о 100 юзерах в секунду :)
Во-вторых, эти тесты не показывают реальной нагрузки, потому что они просто долбятся в одну страницу. Там сама ОС и серверный софт справляется с подобной топорной нагрузкой в десятки раз лучше, чем если бы это было при 15 юзерах в секунду реальной нагрузки.
Поэтому тестируйте юзера 3 в секунду, это более адекватно и для подобных ресурсов и для апача :)
я не знаю в чем там может быть дело, но nginx наоборот должен отдавать файлы гораздо быстрей. Возможно проблема в проигрывателе.
пошагово:
Эту строчку добавить в /etc/nginx.conf, в контекст http:
limit_conn_zone $binary_remote_addr zone=perip:10m;
А такой фрагмент в конфиг нужного сайта, в контекст server:
location ~* ^.+\.(avi|mp4)$ {limit_conn perip 1;limit_rate 512k;}
Что в итоге ограничит полосу пропускания до 0,5мбит/сек на каждое соединение, а количество соединений до одного на каждый клиентский IP. Со вторым следует аккуратней, ибо рискуете блокировать каких-то клиентов, подключающихся с одного IP. Я бы не стал использовать ограничение на количество коннектов.
Не пойму почему вопрос стоит именно так. Если у вас проблема в сомнительности работы провайдера, то надо просто сменить провайдера. Вопрос об отказоустойчивости как-то бессмысленно ставить, если дело в нестабильности подключения. Какой-то dyndns надо выдумывать. Обычно в отказоустойчивость делают когда в разных ДЦ дублируют серверы, получается кластер.
Ну и потом, round-robin - это круговой опрос серверов за А-записью, насколько я знаю, поэтому оно тоже должно решать проблему, если один из серверов лег. Никакой трафик не должен при этом теряться. Именно так работают крупнейшие соцсети, и сервисы:
