В соответствии с июньской статистикой (http://stat.webnames.ru/?show=http&what=&date=1306872000) распределения популярности http-серверов, опубликованной сервисом WebNames.ru, nginx (http://www.sysoev.ru/nginx/) обслуживает более половины хостов рунета. Доля Apache составляет 37.47%, nginx - 51.11%, IIS - 5.54%, иных серверов - 5.87%. Следует заметить, что в большинстве конфигураций nginx используется в качестве фронтэнда к Apache, т.е. присутствие Apache значительно шире, чем указано. Статистика основана на результате опроса более 4 млн доменов в зоне RU.<center><a href="http://stat.webnames.ru/?show=http&what=fullstats">&... src="http://www.opennet.ru/opennews/pics_base/30783_1307215340.jp... style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
URL: http://stat.webnames.ru/?show=http&what=fullstats
Новость: http://www.opennet.ru/opennews/art.shtml?num=30783
Ну а что, хороший шустрый и функциональный сервак. Может даже без апача работать. На отдаче статики делает апач с разгромным счетом.
>Ну а что, хороший шустрый и функциональный сервак.
>Может даже без апача работать.
>На отдаче статики делает апач с разгромным счетом+1
сам уже давным давно перешел на связку nginx + php-fpm
Равных ему по скорости, и по потреблению ресурсов ИМХО нет..!
Аналогично. Удобно, быстро, мало жрет. Если отсутствует необходимость в большинстве продвинутых фич апача - то вообще равных нет.
> Если отсутствует необходимость в большинстве продвинутых фич апачаУважаемые коллеги, у меня к вам большая ко всем просьба: перечислите мне "продвинутые фичи Apache", которых нет в nginx.
Лично _меня_ беспокоит одно: отсутствие аналога mod_dav_svn для nginx.
Может быть, я плохо искал, если оно находится Google'ом -- не сочтите за труд дать поисковый запрос.
Что ещё есть в Apache такого, чего нет в nginx? Я ответить на этот вопрос затрудняюсь.
Да элементарно - CGI!!! Автор был настолько упорот и настырен, что людям пришлось делать ДВА вебсервера: второй - апач, как раз для обслуживания ЦГИ! Смех, да и только...
?!spawn_fcgi?
> spawn_fcgi?CGI != FCGI
>> spawn_fcgi?
> CGI != FCGIА, понял.
Пример для Перла: http://wiki.nginx.org/SimpleCGI
Я понимаю здесь Сысоева: гораздо проще написать враппер на Перле на 2К, чем ввязываться в написание двухмодового сервера (FSM+Prefork).
Это проблема -- использовать враппер? Только без троллинга, пожалуйста. ;)
> чем ввязываться в написание двухмодового сервера (FSM+Prefork).Ну так Сысоев в свом деле шарит: он не собирается делать фичи которые затормозят FSM-модель сервера. И правильно делает! Именно поэтому его сервак и жжот напалмом, легко выдерживая нагрузку которая превратит апача в пинаемый клиентами труп.
> Да элементарно - CGI!!!CGI маздай. Уродский и тормозной протокол эпохи каменного века. Еще большее гумно мамонта чем сам апач с его форками. Если вам нравится форкать процессы - запустите форкбомбу! Зачем ждать пока шк0л0л0 устроят вам ее своими ab2/http_load/siege'ами? :)
> Что ещё есть в Apache такого, чего нет в nginx?В nginx нет нормального листинга каталогов (иконки, инклудинг HEADER, README в вывод листинга). Неофициальные моды для этого из портов FreeBSD - крайне кривы. Кроме того - нет опции "user pupkin zolupkin etc" как перечень разрешённых юзеров в файле паролей. Из-за этого приходится для разного допуска плодить кучу файлов паролей с одинаковыми юзерами.
>> Что ещё есть в Apache такого, чего нет в nginx?
> В nginx нет нормального листинга каталогов (иконки, инклудинг HEADER, README в вывод
> листинга). Неофициальные моды для этого из портов FreeBSD - крайне кривы.Это mod_autoindex в Apache?
> Кроме того - нет опции "user pupkin zolupkin etc" как перечень
> разрешённых юзеров в файле паролей. Из-за этого приходится для разного допуска
> плодить кучу файлов паролей с одинаковыми юзерами.Не догнал. HTTP Basic Auth говорит либо Allow, либо Deny, Что значит "для разного допуска"?
> Это mod_autoindex в Apache?Да. В нём много отлаженных годами возможностей.
> Не догнал. HTTP Basic Auth говорит либо Allow, либо Deny, Что значит
> "для разного допуска"?В nginx используется такая функция:
auth_basic "Restricted Access";
auth_basic_user_file /usr/local/etc/nginx/htpasswd;При этом ВСЕ, кто перечислен в файле htpasswd, после ввода пароля получают доступ к каталогу / файлу.
В Apache же есть такой синтаксис:
AuthType Basic
AuthUserFile /usr/local/etc/apache2/htpasswd
AuthName "Restricted Access"
require user pupkin zolupkinПри этом в файле htpasswd может быть сколько угодно пользователей, но доступ к каталогу / файлу будут иметь ТОЛЬКО юзеры pupkin и zolupkin.
В виду невозможности задать имя конкретных юзеров в nginx, для доступа к каждому каталогу / файлу приходится создавать отдельный файл паролей и дублировать в нём одинаковых пользователей, что очень неудобно (менять пароли, иметь кучу файлов паролей и т. п.).
> Да. В нём много отлаженных годами возможностей.Спасибо вам за этот модуль, господа ретарды. Через него так удобно сливать внутренние сущности, которые вы не планировали изначально светить всему миру - от бакапов сайта до побочных фотографий которые одмин сдуру выложил под свои нужды ;)
> При этом ВСЕ, кто перечислен в файле htpasswd, после ввода пароля получают
> доступ к каталогу / файлу.Что вроде бы логично. Файл указывает кому и что льзя. Это хорошо.
> При этом в файле htpasswd может быть сколько угодно пользователей, но
> доступ к каталогу / файлу будут иметь ТОЛЬКО юзеры pupkin и
> zolupkin.Замечательно, ага! Авторизация размазана по 2 местам. Это же так приятно - в мозгу эффективный ACL самому комбинировать. Из двух файлов. И это совсем не провоцирует ошибки.
> В виду невозможности задать имя конкретных юзеров в nginx, для доступа к
> каждому каталогу / файлу приходится создавать отдельный файл паролей и дублировать
> в нём одинаковых пользователей, что очень неудобно (менять пароли, иметь кучу
> файлов паролей и т. п.).Зато можно сразу посмотреть - у кого к ресурсу доступ. В *одном* файле а не в пяти разных местах. Это и баг и фича. Фича - потому что так проще оценивать у кого доступ. Баг потому что то что вы указали, да. Тем не менее, уважающий себя *никсоид должен уметь скроить за 2 минуты команду которая во всех файлах заменит пароль одним чихом, нарисуйся у него такая нужда. Так что это очень небольшая и незначительная "бага", вообще не достойная упоминания.
> Спасибо вам за этот модуль, господа ретарды. Через него так удобно сливать
> внутренние сущности, которые вы не планировали изначально светить всему миру -
> от бакапов сайта до побочных фотографий которые одмин сдуру выложил под
> свои нужды ;)Тщательнее надо быть. Security by obscurity никому не помогало.
> Тщательнее надо быть. Security by obscurity никому не помогало.А теперь идите и расскажите это всем тем лохам, у которых опачи радостно индексят диры мне на радость :). Практика показала: лохов много, интересных файлов у них - тоже. Вот так при помощи клавиш со стрелками и кнопки bkspace на клаве можно внезапно "расхакать" немало кульных серваков :D. А все потому что админы поставили свое удобство выше безопасности и включили этот модуль на свой зад.
>> Тщательнее надо быть. Security by obscurity никому не помогало.
> А теперь идите и расскажите это всем тем лохам, у которых опачи
> радостно индексят диры мне на радость :). Практика показала: лохов много,
> интересных файлов у них - тоже. Вот так при помощи клавиш
> со стрелками и кнопки bkspace на клаве можно внезапно "расхакать" немало
> кульных серваков :D. А все потому что админы поставили свое удобство
> выше безопасности и включили этот модуль на свой зад.А теперь расскажите про страшную дыру в Линукс под названием "пароль по умолчанию 12345 на вывешенном наружу веб-интерфейсе в раутерах %company_name%".
> Спасибо вам за этот модуль, господа ретарды. Через него так удобно сливать внутренние сущности, которые вы не планировали изначально светить всему миру - от бакапов сайта до побочных фотографий которые одмин сдуру выложил под свои нужды ;)Nginx тоже прекрасно выводит листинг каталогов. Только без иконок и включения в вывод заданных файлов. Т.е. - "светит" он в той же степени.
> Это и баг и фича. Фича - потому что так проще оценивать у кого доступ. Баг потому что то что вы указали, да.
Должна быть возможность выбора под конкретные задачи.
> Тем не менее, уважающий себя *никсоид должен уметь скроить за 2 минуты команду которая во всех файлах заменит пароль одним чихом, нарисуйся у него такая нужда
Ни кто никому ничего не должен. В данном случае - это костыли.
> Nginx тоже прекрасно выводит листинг каталогов. Только без иконок и включения в
> вывод заданных файлов. Т.е. - "светит" он в той же степени.У него по дефолту этот модуль сроду неактивен. Ни разу еще не удалось ничего умыкнуть с нжинкса таким макаром. А вот с апачей - сколько влезет. Чисто статистческое наблюдение: на жнинксе с потугой залистть диру почти гарантированно пошлют. А на апачах 50/50 где-то.
> Должна быть возможность выбора под конкретные задачи.
Вообще не вижу проблем: ну если надо много и часто - написали себе скриптик вида change_pass <user> <newpassword> за 2 минуты и забыли о проблеме. Тоже мне проблему нашли.
> Ни кто никому ничего не должен. В данном случае - это костыли.
Обычная системная автоматизация и упрощение жизни. Прописка прав в 2 местах - тоже костыли, при том если первое ведет лишь к небольшому неудобству, второе ведет к возможности облажаться в персиссиях с невкусным результатом (кому-то недосыпят или пересыпят прав, что как-то не есть хорошо - хорошо когда все права сразу на виду).
> Обычная системная автоматизация и упрощение жизни. Прописка прав в 2 местах -
> тоже костыли, при том если первое ведет лишь к небольшому неудобству,
> второе ведет к возможности облажаться в персиссиях с невкусным результатом (кому-то
> недосыпят или пересыпят прав, что как-то не есть хорошо - хорошо
> когда все права сразу на виду).То есть, все "миллионы лет" эволюции *nix-систем зря? Ведь там тоже логин и пароль хранятся в одном месте, а права на объекты выдаются только с помощью логина(uid'а/gid'а, если быть точным)? Да-да-да, надо было держать master.passwd в каждом каталоге, как же они не догадались! А чтобы сменить пароль пользователю нужно всего лишь написать простой скрипт, который обойдёт весь диск и обновит master.passwd в каждом каталоге. Гениально!
> Уважаемые коллеги, у меня к вам большая ко всем просьба: перечислите мне
> "продвинутые фичи Apache", которых нет в nginx.- поддержка AJP
> Равных ему по скорости, и по потреблению ресурсов ИМХО нет..!lighttpd быстрее
Сильно зависит от. В многоядерной конфигурации у нжинкса больше шансов быть шустрее, распихав по воркеру на ядро.
> lighttpd быстрееПроверено, lighttpd процентов на 20% медленнее при отдаче статики и проксировании на одноядерном CPU, на многоядерных системах nginx в разы может обгонять lighttpd. Почитайте презентацию процесса миграции WordPress на nginx, там достаточно подробно на реальной нагрузке сравнивались разные http-серверы.
> презентацию процесса миграции WordPressА ссылку?
> Проверено, lighttpd процентов на 20% медленнее при отдаче статики и проксировании на
> одноядерном CPU,А как/чем проверялось, если не секрет? Всегда хотел сравнить их но никогда не доходили руки до запуска на одинаковой конфигурации.
Показательно!
В зоне ру невероятное количество сайтов, для которых крайне важна именно отдача статики!
Ну ничего, лет через 20 или 30 научимся и динамические сайты делать! Я уверен!
Я тоже уверен что лет через 20 или 30 даже такой дурак как ты научится с помощью кеширования делать из динамики - статику. Хотя ... пожалуй я оптимист по отношению к тебе :)
> делать из динамики - статикуОга. В соцсетях.
Нет, я, действительно, не понимаю, зачем "для динамики" Apache.Вот взять, к примеру, меня. У меня есть phpBB, WordPress и MediaWiki. Но вот Apache как-то нет.
ЧЯДНТ?
> Нет, я, действительно, не понимаю, зачем "для динамики" Apache.Наверное потому что ленивые и тупые не могут освоить прикольные фичи нжинкса, типа кеширования. А кеширование - это такая крутая штука, когда вы можете спокойно выдержать хабра/слэшдот/чтотамещеэффект на откопанном пентиум 3 из пыльной кладовки. Не делая дорогущую ферму на ксеонах, которая потребовалась бы чтобы все это же в реальном времени генерить опачами на каждый запрос, каждому юзеру. А зачем 5000 раз в секунду генерить одно и то же? :)
>...на откопанном пентиум 3 из пыльной кладовки.Это не укладывается в концепцию энтерпрайза, где под каждую фичу покупается дорогущая ферма на ксенонах.
бгг, ксеноны противоречат ПДД :)
Это не укладывается в концепцию откатов с дорогущих ферм.
За тем, что бы было на что порш каен купить
> За тем, что бы было на что порш каен купитьВам даже на зарплату учителя русского языка видимо не хватило. Не то что на порш. :P
>> делать из динамики - статику
> Ога. В соцсетях.Да.
> Ну ничего, лет через 20 или 30 научимся и динамические сайты делать!Да, да. А картинки, шрифты, стили, музыка и т.д. все через астрал передаваться будет.
> Ну ничего, лет через 20 или 30 научимся и динамические сайты делать! Я уверен!Вы еще не видели как нжинкс кеширует динамику. Там где вы умрете под 50 одновременными юзерами с вашим опачом, нжинкс легко вытянет 5000, если мозг задействовать. А у опача и близко нет такого удобного управления кешированием...
Ну ка расскажите мне про то, как вы будете кэшировать к примеру список новых комментариев к тем статьям, которые читал конкретный пользователь, когда у вас хотя бы с десяток юзеров на сайте за последнюю минуту и каждый из них может написать новый комментарий в любой момент?
В таком случае нужно event-based cache management применять. Т.е. сбрасывать/обновлять весь релевантный кэш (а его еще надо найти, а еще хранить индивидуально под каждого пользователя свой).
Кэширование нужно применять там, где в нем есть смысл. Например скэшировать 100 картинок со страницы и быстро отдать их. Но лучше отправить верстальщика на учебу, где он освоит спрайты и вместо 100 картинок будет 1. И о чудо, сервер перестанет загибаться от нагрузки потому, что вместо 1000 запросов к серверу будет 10.
> минуту и каждый из них может написать новый комментарий в любой момент?Ну не увидит юзер коменты за последнюю секунду. Трагедия, однако :). А как кешировать? Да как обычно. А при написании комента попутно можно инвалидировать кеш, если уж по уму все делать. Правда это оверкилл: непоказ коментов за последнюю секунду большой проблемой не является, если ориантироваться на практику а не эстетствовать :P
> Кэширование нужно применять там, где в нем есть смысл.
Ну вот когда вас опубликуют на сдешдоте/хабре/чем там еще - узнаете где в нем есть смысл :)
> Например скэшировать 100 картинок со страницы и быстро отдать их.
Чего? Кого? Зачем? Кешируют обычно результат работы скриптов, чтобы не дергать на всю толпень юзеров постоянно серверные скрипты. А то если вам 5000 одновременных юзеров придет - вы немного задолбаетесь на них php или что там у вас в 5000 экземплярах дергать. А в статику закешить - и пусть отдается себе. Ну будет страница с коментами 1-секундной давности. Ужас!
> И о чудо, сервер перестанет загибаться от нагрузки потому, что вместо 1000 запросов к серверу будет 10.
О чудо, любой школотенок с ab может прийти к вам с своего вшивого диалапа 1000й "юзеров". Параллельных потоков. Когда опач форканет 1000 процессов и пых попробует выполнить скрипт в 1000 копий - сервер радостно и быстро сдохнет. Классический метод уронить дефолтовый апач :). Ему много лет и он до сих пор работает. Поскольку затраты ресурсов на стороне клиента много меньше затрат сервера на их обслуживание.
> Ну не увидит юзер коменты за последнюю секунду. Трагедия, однако :). АА если у вас магазин? Товар допустим купили, а человек делает свой заказ и получает отказ перед самым носом потому, что этот товар только что купили. А если бы увидел актуальные данные, возможно выбрал бы другой товар. А так у него будет негативная ассоциация.
> А при написании комента попутно можно
> инвалидировать кеш, если уж по уму все делать.Про это я выше написал.
> Ну вот когда вас опубликуют на сдешдоте/хабре/чем там еще - узнаете где
> в нем есть смысл :)Знаем.
Насчет школоты есть соответствующие ограничения. Ни один разумный админ не будет оставлять апач по умолчанию.
Динамика должна оставаться динамикой. Она для этого была создана.
Не распаляйтесь на школоло - им законы физики вообще нипочём! :) "Ну не увидит юзер коменты за последнюю секунду. " - разве не виден ламерский подход?Кэш - это всё забавно, но "динамика" названа динамикой не потому, что другого слова не нашлось, а потому, что это ПРОТИВОПОЛОЖНОСТЬ статике. Но не всем это дано понять...
> не всем это дано понять...Ой, а вот через секунду после того как мне ваш сервак страницу отдал, там новый юзер откоментил. А чойта эта ваша динамика не генерит мне страницу заново и не показывает его? Как максимум что-то такое делается на аяксе, только это не противоречит использованию нжинкса и тормознутость в основном определится архитектурой серверной стороны приложения, насколько оно эффективно обрабатывает множественные параллельные запросы. При этом кстати можно быстро выстрелить тяжелые части статикой из кеша, а остальное подтянуть аяксом по мере готовности и ненапряжно для юзера. Опач с его форками на каждое соединение опять не у дел - при постоянном висении тысяч юзеров он с его толпами процессов просто умрет.
> А если у вас магазин? Товар допустим купили, а человек делает свой
> заказ и получает отказ перед самым носом потому, что этот товар
> только что купили.Как ни странно, наиболее вменяемые магазины делают именно так: собирается корзина. Из товаров которые предположительно есть. На окончательном этапе сборки заказа чекается есть ли товар по факту на складе. Если да - заказ создан. Нет - отлуп.
Дело тут в том, что даже если вы слазили в базу и сгенерили мне страничку по актуальному состоянию товаров, пока я вдуплял чего бы мне заказать, этот товар вполне могли уже купить. Вот только страничка об этом ... не знает. Более того, пока я клал в корзину 10 наименований, из них 2 вполне могли раскупить. Апдейтить мне в реалтайме страницу или постоянно проверять не протухли ли даннык корзины - никакая БД не выдержит при мало-мальски популярном магазине. Поэтому это делается 1 раз - при окончательном создании заказа. Это нормально и всех устраивает.
> А если бы увидел актуальные данные, возможно выбрал
> бы другой товар. А так у него будет негативная ассоциация.Она у него и так может возникнуть. Вот показывает юзеру страница что есть товар. Ну, на момент генерации и запроса в базу - был. Юзер минуту смотрел на нее и выбирал. Выбрал. А за эту минуту бац и кто-то взял и раскупил как раз то что он выбрал. Совершенно штатная ситуация для популярного магазина. Юзер обламывается. Ну и в чем выигрыш то? Возможность такой ситуации все-равно осталась.
>> А при написании комента попутно можно
>> инвалидировать кеш, если уж по уму все делать.
> Про это я выше написал.Про магазин? Так в вашем варианте юзер тоже может обломаться: вы же не можете юзеру постоянно генерячить новые версии страниц и вдувать ему новую версию страницы на любое изменение базы. Ну то-есть теоретически это можно, но практически такую жесть никакой сервер не выдержит + излишне сложно. Обычно юзеров именно посылают на окончательном оформлении заказа. Это нормально, привычно, реалистично. С идеей кеширования особо не воюет. И более того - это может сделать только зареганый юзер. Который если будет наглеть сильно дергая сервер, просто лишится своего аккаунта и более дергать эту операцию не сможет.
> Насчет школоты есть соответствующие ограничения. Ни один разумный админ не будет оставлять
> апач по умолчанию.А ограничения знаете ли ведут к другой проблеме. Если я залимитирую число процессов/тредов опача, в случае когда вредитель занял собой все процессы/треды, легитимные юзеры вообще хрен дождутся своей очерели. Словят таймаут в браузере и отвалят восвояси. Не сильно лучше варианта лютой смерти сервака от форка кучи процессов.
> Динамика должна оставаться динамикой. Она для этого была создана.
Динамика должна быть таковой только там где это оправдано. Пример с товарами - не катит: список товаров устарел сразу же после выдачи, а постоянно актуализовывать полное состояние ваших складов на всех юзеров - никаких серверов не хватит. А если на юзере нет полного сосояния всех товаров на складе - оно тогда всяко не синхронно с вами и возможны накладки. Ы? :)
Мне интересен такой момент, как то, откуда кэшсервер узнает, авторизован юзер или нет?
Например у меня по одному и тому же URL сайт обязан открываться совершенно по-разному для авторизованного и неавторизованного пользователя.
Ну а про блоки типа "вы уже смотрели" или выдачи материала в зависимости от запроса в поисковике наверно прийдется забыть.
> Мне интересен такой момент, как то, откуда кэшсервер узнает, авторизован юзер или
> нет?
> Например у меня по одному и тому же URL сайт обязан открываться
> совершенно по-разному для авторизованного и неавторизованного пользователя.никак, кэш на уровне httpd не твой случай
> Ну а про блоки типа "вы уже смотрели"
реализуемы через ajax
> или выдачи материала в
> зависимости от запроса в поисковике наверно прийдется забыть.ну так не кэшировать URL
> реализуемы через ajaxЭто увеличивает число запросов к серверу и усложняет архитектуру веб-приложения.
> ну так не кэшировать URLчто это значит?
Получается, что кэширование вредно? Или даже не так.
Получается, что кэширование применимо далеко не ко всем задачам.
Еще раз прихожу к выводу, что nginx-frontend & apache=backend неплохая связка.И так получаем: использование nginx как кэширования динамики применимо только к высоконагруженным новостным/read-only/slowupdated сайтам и никак к магазинам и прочим web-apps.
>[оверквотинг удален]
> минуту и каждый из них может написать новый комментарий в любой
> момент?
> В таком случае нужно event-based cache management применять. Т.е. сбрасывать/обновлять
> весь релевантный кэш (а его еще надо найти, а еще хранить
> индивидуально под каждого пользователя свой).
> Кэширование нужно применять там, где в нем есть смысл. Например скэшировать 100
> картинок со страницы и быстро отдать их. Но лучше отправить верстальщика
> на учебу, где он освоит спрайты и вместо 100 картинок будет
> 1. И о чудо, сервер перестанет загибаться от нагрузки потому, что
> вместо 1000 запросов к серверу будет 10.redis+nginx+версионирование кэша по ключам.
Nginx рисует ssi по путям, который ему отдал редис, которые формируют в редисе динамические виджеты.
Если что-то надо изменить, то по маске удаляем из редиса все измененное и рисуем заново. Если продумать схему страницы по виджетам, и продумать дерево виджетов, то получается очень неплохо. Кэшировать можно практически все и везде.
гон всё это. за 90% из этого кол-ва nginx'ов стоят апачи...
В новости именно так и написано.
Тогда в чем новость? nginx в принципе существует? Ну да, мы в курсе :-)
В том, что его доля увеличилась с 20% в прошлом году до 50% в этом. О чем это говорит? Ты уж будь добр подумай сам.
20 - не в прошлом, а 3 года назад
надо еще было один график нарисовать: 90% Апач + nginx
> надо еще было один график нарисовать: 90% Апач + nginxНе факт что 90%. Я вот опач совсем не юзаю. А зачем?
А кривая динамики эмэсовского IIS доставляет, хе-хе...
Ынтерпрайз
Но они все равно счастливы :D
Внимание, реклама m$!
> Но они все равно счастливы :D
> http://habrahabr.ru/blogs/modx/120282/Да конечно, можно заплатить тонну бабок за монструозные тормозные решения майкрософт. Но зачем, если не хуже, а как правило даже лучше - получается совершенно бесплатно на открытом софте?! Это какой-то тонкий вид мазохизма - заплатить много денег, влипнуть в зависимость от MS и получить решение, которое по параметрам просрет бесплатному. Если б это было не так - ну наверное, даунлоады MS не отгружал бы AKAMAI на пингвинах? :)
> Да конечно, можно заплатить тонну бабок за монструозные тормозные решения майкрософт. Но
> зачем, если не хуже, а как правило даже лучше - получается
> совершенно бесплатно на открытом софте?!Затем, что M$ - это не просто "выучил сишарп и слабал асп-шку" (как принято в FOSS) - это целая инфраструктура, где мелкософт несёт ответственность за все свои продукты: от своевременной поставки заплаток до обучения всем тонкостям продукта. Если у вас есть задача, к ней всегда найдётся мелкомягкое решение (пусть не всегда оптимальное, но гарантированное). Это и отличает Ынтепрайз - покупка лекарства от головной боли "как прикрутить к нгынксу астериск с пробросом хэсервера через ssh". Плюс сюда (опять же гарантированное) наличие спецов по платформе, прогеров и т.д. - не нужно бегать по форумам в жалкой надежде, что такой же бедолага как вы пытался скрестить Хэсервер с Voodoo 3D.
Это не агитация, это объяснение к вопросу "но зачем". :) Сам юзаю линукс, но для некритичных вещей.
>где мелкософт несёт ответственность за все свои продукты:А вот я в еуле читал об отказе Майкросовта от ответственности, и об его обязанности в случае чего возместить ущерб в размере стоимости продукта, ну или пяти баксов. Не сходится.
>> Да конечно, можно заплатить тонну бабок за монструозные тормозные решения майкрософт. Но
>> зачем, если не хуже, а как правило даже лучше - получается
>> совершенно бесплатно на открытом софте?!
> Затем, что M$ - это не просто "выучил сишарп и слабал асп-шку"
> (как принято в FOSS) - это целая инфраструктура, где мелкософт несёт
> ответственность за все свои продукты:<b>от своевременной поставки заплаток до обучения всем тонкостям продукта.</b>
Вот это особенно толсто
> Если у вас есть задача, к ней всегда
> найдётся мелкомягкое решение (пусть не всегда оптимальное, но гарантированное). Это и
> отличает Ынтепрайз - покупка лекарства от головной боли "как прикрутить к
> нгынксу астериск с пробросом хэсервера через ssh". Плюс сюда (опять же
> гарантированное) наличие спецов по платформе, прогеров и т.д. - не нужно
> бегать по форумам в жалкой надежде, что такой же бедолага как
> вы пытался скрестить Хэсервер с Voodoo 3D.
> Это не агитация, это объяснение к вопросу "но зачем". :) Сам юзаю
> линукс, но для некритичных вещей.
>> Если у вас есть задача, к ней всегда найдётся мелкомягкое решение (пусть не всегда оптимальное, но гарантированное).У меня есть задача: концентратор PPPoE с поддержкой QinQ (4094 абонентских CVLAN внутри каждого из двух десятков SVLAN), Radius, CoA, ...
Не подскажете мелкомягкое решение?
>> Да конечно, можно заплатить тонну бабок за монструозные тормозные решения майкрософт. Но
>> зачем, если не хуже, а как правило даже лучше - получается
>> совершенно бесплатно на открытом софте?!
> Затем, что M$ - это не просто "выучил сишарп и слабал асп-шку"
> (как принято в FOSS) - это целая инфраструктура, где мелкософт несёт
> ответственность за все свои продуктыО да. Коллега ушел в контору, где кто-то из руководства полагает так же. В итоге имеет некислый гемор с эксченджем (глюк, который известен с 2009го года - workaround прямо противоречит документации) и еще парой мелкомягких поделий. Где сервис пак для TMG требует IE9, но сам TMG НЕ РАБОТАЕТ С IE9! Это ваш Ынтерпрайз? Я пропущу. В любой день.
> TMG НЕ РАБОТАЕТ С IE9! Это ваш Ынтерпрайз? Я пропущу. В
> любой день.Спасибо, мил человек. Похоже, я теперь знаю, почему у клиентов консоль TMG не работает.
>> TMG НЕ РАБОТАЕТ С IE9! Это ваш Ынтерпрайз? Я пропущу. В
>> любой день.
> Спасибо, мил человек. Похоже, я теперь знаю, почему у клиентов консоль TMG
> не работает.В принципе коллега уверждал, что если что - лезте в инет и гуглите. На форуме находите решение - и каким бы идиотским не казалось - просто делаете. Если написано - поставить вторую сетевуху (просто поставить, даже не включать) - и все заработает - делайте. Наверняка заработает.
> В принципе коллега уверждал, что если что - лезте в инет и
> гуглите. На форуме находите решение - и каким бы идиотским не
> казалось - просто делаете. Если написано - поставить вторую сетевуху (просто
> поставить, даже не включать) - и все заработает - делайте. Наверняка
> заработает.Да я гуглил. Но это же не Linux/FreeBSD, где можно быстро найти точный ответ. Ошибок-то внятных не пишется.
> мелкомягких поделий. Где сервис пак для TMG требует IE9, но сам
> TMG НЕ РАБОТАЕТ С IE9! Это ваш Ынтерпрайз? Я пропущу. В любой день.Особенно эпично было на одном мсовском же сайте:
сайт> Для улучшения работы наших продуктов скачайте сильверлайт! Вот вам ссылочка! Тогда вы сможете видеть прогресс аплоада ваших файлов, а ваши волосы станут белыми и пушистыми.
юзерь> Хрен с вами, давайте.
(скачивается и ставится эта хрень)
юзерь> WTF?! Файло теперь совсем не аплоадится?! Что за на?!
гугл> knowledge base сообщает, что есть баг: этот сайт некорректно работает с сильверлайтом.EPIC FAIL!!!
P.S. не в обиду этим инвалидам, показать прогресс аплоада файла на сервак можно и без их многомегового фреймворка и ассоциированых с ним багов. Маленький и скромный нжинкс это вполне позволяет, кстати. Без идиотских багов в немеряном knowledgebase по супер-мега-турбо-фреймворкам.
>это целая инфраструктура, где мелкософт несёт ответственность за все свои продукты: от своевременной поставки заплаток до обучения всем тонкостям продукта.
>(опять же гарантированное) наличие спецов по платформе, прогеров и т.д. - не нужно бегать по форумамКак человек, имевший дело с техподдержкой мелкософта, могу сказать: они ни за что не отвечают, а их "спецы" сами ничего не понимают в своих продуктах. Вся поддержка сводится к более или менее вежливому посыланию клиентов на три буквы. А клиенты за это еще и деньги платят.
> Затем, что M$ - это не просто "выучил сишарп и слабал асп-шку"
> (как принято в FOSS) - это целая инфраструктура,Инфраструктура,блаблабла. Энтерпрайз, во! Большое, тормозное, монструозное... глюкало.За кучу денег.Гадость!Добровольно это может захотеть поддерживать только идиот или мазохист.
> где мелкософт несёт ответственность за все свои продукты:
Почему-то в лицензии написано AS IS, отказ от гарантий и все такое. Максимум который я видел - в пределах особо тонкого стеба они обещали в лицензии нести ответственность. Аж в пределах целых $5! А ничего что эта их винда и сиквели - "немного" дороже? :D
> от своевременной поставки заплаток
Раз в месяц. Своевременнее некуда, лол :). Кстати, 9й ишак который на контроллер домена зачем-то накатывается, с требованием его по этому поводу перезагрузить - это довольно интересное понимание о своевременной поставке заплаток. По-моему, админа который с DC ходит в интернет надо расстрелять без суда и следствия, а потом разберемся.
> до обучения всем тонкостям продукта.
Ой, всем тонкостям... они свои многочисленные баги годами не чинят. В новых продуктах нынче вообще глюкодром адский, все тормозит, а шаг в сторону = глюки, которые не разрулит никакой саппорт. Есть сомнения что их унылая индусня вообще разбирается в тонкостях.
> Если у вас есть задача, к ней всегда найдётся мелкомягкое решение (пусть не всегда
> оптимальное, но гарантированное).Гарантированное? На LSE они уже нагарантировались. В результате получили пинка под зад в том числе и за то что не смогли обеспечить заявленные времена транзакций. Грош цена таким гарантерам.
> Это и отличает Ынтепрайз - покупка лекарства от головной боли "как прикрутить к
> нгынксу астериск с пробросом хэсервера через ssh".Да ну бросьте, мало-мальски нестандартную проблему саппорт мс в жизни не разрулит. И вот вы уже 1 на 1 с вашей проблемой. И даже если до мс каким-то чудом допрет что вон то и правда баг, совсем не факт что они со своей бюрократией хотя-бы за 2 месяца вам его починят.
> Плюс сюда (опять же гарантированное) наличие спецов по платформе,
Унылых тупых эникеев, которые в случае проблем сливают, бегут как крысы с корабля и прочая. На LSE такие молодчики дружно обделались, завалив торги на 8 часов. Убедительнее некуда.
> прогеров и т.д. - не нужно
Прогеров? Г@%нАк0дИров, не более. Особенно среди дотнетчиков. На LSE они себя уже показали. Прогеры-индусы гарантировали, гарантировали, а в результате и времена транзакций не обеспечили, да еще и торги уронили на 8 часов, в течение которых никто не мог эту индуястину вообще оживить. Нормальных програмеров под винду не так уж много. Более того - почему-то есть ощущение что у *никсных програмеров код в целом более качественный.
> бегать по форумам в жалкой надежде, что такой же бедолага как
> вы пытался скрестить Хэсервер с Voodoo 3D.На кой черт в энтерпрайзе сдалось скрещивать иксы с ископаемым видеоакселератором? Если в энтерпрайзе вылезает такой вопрос, его надо переформулировать в "кого нам надо уволить?" :)
> Это не агитация, это объяснение к вопросу "но зачем". :) Сам юзаю
> линукс, но для некритичных вещей.А гугл, фэйсбук и даже LSE вполне себе используют для критичных вещей. Наверное, секрет в том что вы можете или сами чинить проблемы или купить саппорт например у редхата, etc которые это смогут. Хорошо при этом то что у вас выбор есть: можете сами упираться, можете найти тех кто будет вам саппорт оказывать. Выбирая из более 1 наименованя компаний.У MS выбора нет (исправить баги без сырцов малореално и долго) а саппорт особым качеством не страдает.Они уже пулично обделались с своими гетзефакс и гарантиями на LSE. Куда уж критичнее и убедительнее чем заваленные на 8 часов торги?!
Прям контрольный пакет :) (51%)
Контрольный пакет - это 50% плюс "золотой сервер" (очевидно, sysoev.ru) :))
Пока nginx не научится понимать .htaccess и mod_rewrite он вряд-ли сможет заменить на 100% apache
Как только научится - apache будет лично для меня мертв - PHP скрипты спокойно будет обрабатывать PHP-FPM
А, да, еще не хватает open_basedir
open_basedir в php.ini всегда была
> Пока nginx не научится понимать .htaccess и mod_rewrite он вряд-ли сможет заменить
> на 100% apache.htaccess там не будет никогда по очевидным причинам, правила mod_rewrite транслируются в конфиг nginx скриптом, доступным через Web.
На самом деле много чего не хватает. Схема отдачи контента по схеме конечного автомата для динамики малоприменима. Эксперименты с PHP-FPM встречаются, но это скорее извращение для энтузиастов.
... извращения которые вполне чудно обслуживают порталы 1m+ хитов в день.
> Схема отдачи контента по схеме конечного автомата...Ого! Первый раз слышу такой симбиоз. Не поясните, зачем там КА?
>> Схема отдачи контента по схеме конечного автомата...
> Ого! Первый раз слышу такой симбиоз. Не поясните, зачем там КА?Затем, что каждый воркер nginx обрабатывает энное число запросов псевдопараллельно (с использованием как раз таки схемы работы КА), а не как в классике - воркер (не важно, тред или процесс) на запрос.
А насчет 1m+ - я уж не знаю, с чего вы взяли, что nginx на них для динамики используется. nginx на таких ресурсах - это хороший балансер+кеш+статика.
Тем более, что 1m в день, даже с учетом 50% загрузки по времени - это совсем ничего, ~23 хита в секунду. У меня есть нагруженный внутренний ресурс с достаточно тяжелыми запросами и практической невозможностью кеширования, который на апаче ~60 хитов в секунду легко держит всего лишь на двух серверах.
Взял из того, что видел все это изнутри, допиливал и переводил на fbsd. Кстати, хиты == просмотры страниц. Конечно серверов далеко не 2, а еще сервера серверам рознь. В моем случае там просто все не поместится на 2-х серверах, хотя в качестве эксперимента все запускали на 4-х (nginx, 2 x php-fpm, mysql) и работало без затыков. Но с другой стороны - побольше аппликух хороших и разных - каждый найдет свой инструмент для своей задачи. А так - используйте, что хотите, хвалите, что знаете, но попробовать что-то другое можно всегда - универсальных решений на все случаи жизни не бывает.
> У меня есть нагруженный внутренний ресурс с достаточно тяжелыми запросами и практической
> невозможностью кеширования, который на апаче ~60 хитов в секунду легко держит всего
> лишь на двух серверах.- у меня был Apache (worker) + Tomcat на виртуалке (256Мб ОП) который нормально держал 1 мегахит в час (~ 270 хит/сек). Запросы были связаны с использованием БД MySQL (висела на той же виртуалке) - что-то типа чата.
>> У меня есть нагруженный внутренний ресурс с достаточно тяжелыми запросами и практической
>> невозможностью кеширования, который на апаче ~60 хитов в секунду легко держит всего
>> лишь на двух серверах.
> - у меня был Apache (worker) + Tomcat на виртуалке (256Мб ОП)
> который нормально держал 1 мегахит в час (~ 270 хит/сек). Запросы
> были связаны с использованием БД MySQL (висела на той же виртуалке)
> - что-то типа чата.Абсолютно согласен. Т.е. не в nginx/Apache дело. У меня, правда, не чат - там некоторые отчеты по полминуты выполняются...
> На самом деле много чего не хватает. Схема отдачи контента по схеме
> конечного автомата для динамики малоприменима.А вордпрессовский сайт об этом не знает и поэтому работает :)
>> На самом деле много чего не хватает. Схема отдачи контента по схеме
>> конечного автомата для динамики малоприменима.
> А вордпрессовский сайт об этом не знает и поэтому работает :)А с чего вы взяли, что собственно вордпрессовский сайт целиком на nginx? Или вы про личный блог на вордпрессе?
> А с чего вы взяли, что собственно вордпрессовский сайт целиком на nginx?Целиком не целиком, а если туда вместо нжинкса апач поставить - он там сдохнет. А хороший сетевой фронтэнд это уже полдела. И именно апач ему как бэкэнд совсем не обязателен, вообще-то. Более того - не факт что апач лучший вариант бэкэнда. На уровне архитектуры, он болеет тем что при форке на каждый запрос по процессу, память дико загаживается процессами апача. Очень тяжелыми - там висит и пыхпых и сам апач. Уродская какая-то логика.
>> А с чего вы взяли, что собственно вордпрессовский сайт целиком на nginx?
> Целиком не целиком, а если туда вместо нжинкса апач поставить - он
> там сдохнет. А хороший сетевой фронтэнд это уже полдела. И именно
> апач ему как бэкэнд совсем не обязателен, вообще-то. Более того -
> не факт что апач лучший вариант бэкэнда. На уровне архитектуры, он
> болеет тем что при форке на каждый запрос по процессу, память
> дико загаживается процессами апача. Очень тяжелыми - там висит и пыхпых
> и сам апач. Уродская какая-то логика.Почитайте про page sharing / copy on write...
> На уровне архитектуры, он
> болеет тем что при форке на каждый запрос по процессу, память
> дико загаживается процессами апача. Очень тяжелыми - там висит и пыхпых
> и сам апач. Уродская какая-то логика.- уродская логика у того кто собрал Apache как prefork, а потом жалуется что процессы сожрали память и все медленно работает. Соберите его как worker и память чудесным образом освободится, да и производительность вырастет (песня что PHP хреново работает в многопоточном режиме не канает - нормально он работает, а что не работает, то и на preforke к висякам приводит).
> - уродская логика у того кто собрал Apache как prefork, а потом
> жалуется что процессы сожрали память и все медленно работает. Соберите его
> как worker и память чудесным образом освободится, да и производительность вырастет
> (песня что PHP хреново работает в многопоточном режиме не канает -
> нормально он работает, а что не работает, то и на preforke
> к висякам приводит).На Linux prefork - единственный нормальный метод. Расход памяти - как уже говорил - см. механизм page sharing / copy on write, он работает прекрасно, если PHP грамотно поставлен (хоть модулем, хоть CGI). К тому же, падение одного субпроцесса приведет только к отвалу 1 клиента, а не целой пачки, сидящей в тредах.
Т.е. кому надежность отработки нафиг не нужна - юзают worker, остальные - prefork. Кому надо хитрое - скорее всего, как я, юзают mpm_itk.
> На Linux prefork - единственный нормальный метод.- сильный аргумент, кстати Вы сколько Apache-ей и на протяжении какого срока админите?
> К тому же, падение одного субпроцесса приведет только к отвалу 1 клиента,
> а не целой пачки, сидящей в тредах.- теоретически, а практически PHP вешает prefork ничуть не хуже чем worker и форкать новые процессы зависший Apache не может, так же как и создавать новые треды в воркере
> Т.е. кому надежность отработки нафиг не нужна - юзают worker, остальные - prefork.- я сформулирую иначе: те кто думает что префорк надежней чем воркер, маются от расхода памяти и от загрузки ЦПУ
> - сильный аргумент, кстати Вы сколько Apache-ей и на протяжении какого срока
> админите?Лет 10 уже, 7 площадок разного размера, в т.ч. кластерные. К Вам - аналогичный встречный вопрос. Естественно, никаких "портов" и внешних репозиториев, исключительно собственная сборка со своим набором параметров, индивидуальным для каждой площадки.
> - теоретически, а практически PHP вешает prefork ничуть не хуже чем worker
> и форкать новые процессы зависший Apache не может, так же как
> и создавать новые треды в воркереА практически - ни разу не наблюдал такого поведения. Вы под виндой, или может быть просто не так его готовите? PHP вешает максимум один воркер, если у Вас от PHP виснет сам диспетчер - что-то в канцелярии неладно.
> - я сформулирую иначе: те кто думает что префорк надежней чем воркер,
> маются от расхода памяти и от загрузки ЦПУЕще раз: почитайте про page sharing в Linux. А расход динамически распределяемой памяти на каждый процесс PHP аналогичен что для prefork, что для worker. При чем тут CPU - вообще плохо понятно, ибо в Linux нагрузка что от процесса, что от треда - суть одно и то же.
> Лет 10 уже, 7 площадок разного размера, в т.ч. кластерные. К Вам - аналогичный встречный вопрос.- 9 лет, ~ 100 Apache (разных версий 2.0.x, 2.2.x, в основном worker, изредка prefork для особо глючных сайтов) посещаемость самая разная (от 0 до 1 мегахит/час). Собраны из сырцов под Fedora (6,8)/CentOS (5.x) x32 и x64. Про кластерный Apache, к сожалению, слышу впервые.
> А практически - ни разу не наблюдал такого поведения. Вы под виндой,
> или может быть просто не так его готовите? PHP вешает максимум
> один воркер, если у Вас от PHP виснет сам диспетчер -
> что-то в канцелярии неладно.- тем не менее факт, prefork тоже вешается
>А расход динамически распределяемой
> памяти на каждый процесс PHP аналогичен что для prefork, что для worker.- откуда в worker PHP-процессы? (думаю что PHP под worker иначе как модуль запускать бессмысленно). Многопоточная разделяемая библиотека прекрасно экономит оперативку, что очень хорошо заметно при большой посещаемости.
> При чем тут CPU - вообще плохо понятно, ибо в
> Linux нагрузка что от процесса, что от треда - суть одно и то же.- нет, не так, форканье новых процессов на запрос с подгрузкой PHP-интерпретатора также увеличивает загрузку ЦПУ, по сравнению с созданием новых потоков и использованием уже загруженной в ОП so-шки. Кроме теоретического утверждения могу также подтвердить это наблюдениями над некоторыми высоконагруженными проектами, где вынужденно ставил эксперименты по использованию разных сборок Apache.
> Про кластерный Apache, к сожалению, слышу впервые.Кластер может быть собран по-разному. В моем случае наиболее популярна связка Apache+glusterfs+NDBD
> - тем не менее факт, prefork тоже вешается
Вешается воркер, может быть терминирован по времени простоя. На spawning новых процессов это никак не влияет. Если прекращается spawning - значит повис процесс диспетчера, и это уже тревожный сигнал, не связанный с PHP.
> - откуда в worker PHP-процессы? (думаю что PHP под worker иначе как
В контексте обсуждения без разницы - процесс или "тред" (который тоже процесс, в идеологии Linux). Естественно, речь идет о модуле.
> - нет, не так, форканье новых процессов на запрос с подгрузкой PHP-интерпретатора
> также увеличивает загрузку ЦПУ, по сравнению с созданием новых потоковЭто всего лишь fork(), ничего никуда не подгружается - модуль уже в памяти. В случае обработки скрипта дополнительно тратится некоторое время на инициализацию интерпретатора, но в условиях, где не более 1000 запросов в секунду, это - семечки. К слову говоря, то же самое время тратится и в worker на инициализацию интерпретатора в контексте треда.
> использованием уже загруженной в ОП so-шки.
so'шка, кстати, в prefork тоже общая. Она при вызове fork() наследуется от диспетчера в новый процесс.
Кстати говоря, у worker есть существенные проблемы, в т.ч. со стабильностью и с распределением памяти, просто Вы, видимо, с ними не столкнулись. Есть такая вещь, как размер стека на поток... и вот с ней-то связано 99% проблем с масштабируемостью и стабильностью worker.
Ну и у меня как-то так получается, что worker неприменим вообще - ибо надо исполнять несколько вхостов от разных пользователей. Я использую mpm_itk - а это двойной fork() на запрос. Нагрузка мало отличается от классического prefork.
>> А с чего вы взяли, что собственно вордпрессовский сайт целиком на nginx?
> Целиком не целиком, а если туда вместо нжинкса апач поставить - он
> там сдохнет.О5 же, с чего вы это взяли? И где гарантии, что там не апач? Нгинхом хорошо отдавать статику и проксить, для остального существуют другие решения. Хотя проксирование у него - тоже песня, создание файлов для буферизации проксируемого контента - вещь неизбежная, но вот отсутствие возможности перехода для больших ответов в режим чистого сетевого прокси, без хранения - это песня.
