Во многих случаях — разумнее. Однако, если у вас уже активно используется SSI, то почему бы и нет? К тому же, SSI обычно довольно быстр, в отличие от сервер-сайдных скриптов. Ну и, наконец, на больших и нагруженных проектах многие странички отдаются статикой, так что никакого Python/Ruby/PHP там попросту нет. Моё решение как-раз для таких случаев.
Ну просто потому, что так исторически сложилось… Это, кстати, не английский, а, скорее, американский стандарт. Наверное, когда-то древним американцам :) было важнее узнать, какой сейчас месяц. В России, к счастью, такого почти не встречается, но попробуйте-ка разобраться в английской и американской системе мер и весов — все эти футы, дюймы, фунты, ярды и фарлонги способны свести с ума кого угодно, особено, если вспомнить, что длина фута в метрах может отличаться по разные стороны океана. :)
Кстати, в nginx формат по-умолчанию «12 Feb 2009», а не «02/12/09». :)
А ещё мы добавили несколько специальных поисковых подсказок (примеры запросов под строкой поиска), и, возможно, на других проектах тоже будут какие-то сюрпризы. :)
Ага. Только, если бы не это «баловство», мои работодатели могли бы потерять довольно заметные суммы денег, а я, соответственно, работу. Я уже не говорю о том, что даже удалённо, по SSH в *nix, для меня, работать удобнее, чем в Windows, на локальной машине. Только, давайте здесь не будем разводить холивара на тему операционных систем…
Наверное, всё-таки больной, потому что использовать telnet и SSH через GPRS очень даже возможно. И это неоднократно меня спасало как-раз в ситуациях, когда нет никакой связи, кроме GPRS, а что-то нужно срочно сделать.
Собственный шедулинг гораздо дешевле ядерного, как минимум, по причине многократного сокращения времени на переключение контекстов, и вообще, на вход и выход в режим ядра, и обратно.
Ну, мне кажутся условия теста не совсем честными, но, вообще, интересно. Я постараюсь закончить со своими тестами до конца недели, может быть даже попробую сравнить производительность lighttpd и nginx на одинаковых нагрузках.
Почти никаких радостей, кроме возможного уменьшения количества воркеров. Если производительность отдачи файлов nginx ограничена производительностью жёсткого диска, то, в любом случае, сколько-то заметного ускорения отдачи файлов не будет. Впрочем, я надеюсь ещё провести более тщательный тест. Если найдётся время, напишу об этом отдельный пост.
Ну, кстати, возможно, имеет смысл попробовать собрать последний nginx на системе с ядром от РедХат. Они действительно накладывают довольно много патчей, так что всё может и завестись.
Единственное, лучше подождать nginx 0.8.15, потому что в 0.8.14 (последнем на сегодня) уже точно есть как минимум одна ошибка, приводящая в определённых обстоятельствах к сегфолту под линуксом.
А одно другому не мешает. 2.6.18 вышло 20 сентября 2006 года, то есть, ему скоро исполнится три года. За это время столько всего произошло… :)
Хотя, я вас, в принципе, понимаю, я сам бы не стал бы трогать ядро на полностью рабочей системе без необходимости. Но это плата за стабильность — задержка в получении bleeding edge-технологий.
Ну… мне это не показалось уж очень критичным. Время блокировки на чтение одного сектора в 512 байт должно быть достаточно мало, чтобы этого никто не заметил. :)
Скорее уж тогда «пока РедХат не слезет с замшелого ядра 2.6.18». Хотя, если вы ставите все пакеты только из репозитория CentOS, то откуда у вас, вообще Nginx? Тем более, новый… :)
Кстати, в nginx формат по-умолчанию «12 Feb 2009», а не «02/12/09». :)
Очень жаль… :(
Единственное, лучше подождать nginx 0.8.15, потому что в 0.8.14 (последнем на сегодня) уже точно есть как минимум одна ошибка, приводящая в определённых обстоятельствах к сегфолту под линуксом.
Хотя, я вас, в принципе, понимаю, я сам бы не стал бы трогать ядро на полностью рабочей системе без необходимости. Но это плата за стабильность — задержка в получении bleeding edge-технологий.