Потому что sendfile — не асинхронный вызов. При «обычной» передаче данных вы копируете данные сначала из файла, к себе, в адресное пространство процесса, а потом ещё раз — в адресное пространство ядра, когда отправляете их «в сеть». sendfile позволяет избавиться от лишнего копирования в адресное пространство вашего процесса, но вам всё-равно придётся ждать, пока не закончится файловая операция.
Мне кажется, с «вообще незнакомцем» не очень интересно разговаривать. Может быть, имеет смысл предложить людям несколько стандартных тем для общения? Ну, например, «погода» ( :) ), «музыка», «кино», «IT». Обычно, первые фразы в разговоре направлены как-раз на то, чтобы понять, насколько пересекается круг общения у незнакомых людей, и какие темы могут заинтересовать визави. То есть, надо просто помочь людям подобрать несколько первых стандартных фраз.
Я попытался потестировать AIO в разных сценариях нагрузки, и с разными настройками, под Linux. Я предположил, что если настроить nginx на отдачу файлов из каталога /usr и подготовить тестовый файл с url-ами для siege, можно получить достаточно похожую на файл-хостинг нагрузку. Включая по-очереди directio, sendfile и aio в разных комбинациях, можно было бы получить довольно интересную табличку результатов…
Но, дело в том, что тест я проводил на собственном десктопе, где одновременно была запущена целая KDE, так что воспроизводимость результатов теста оказалась… не на высоте. Я надеюсь, у меня когда-нибудь окажется достаточно свободного времени, чтобы провести это же тест в более подходящих условиях. :)
Ага, у меня первая реакция тоже была такая. :) А потом я потестировал новую версию с включенным AIO и без, и немного приуныл. Пользы от файлового AIO на большинстве реальных задач не очень много, реальный выигрыш заметен только при нагрузке, характерной для файл-хостеров, хранилищ фото, видео, и так далее. :)
К сожалению, у Рамблера нет такого количества датацентров и сотрудников, как у Гугла, поэтому полное падение одного датацентра приводит к большим проблемам в работе наших сервисов.
Нам очень жаль, что это произошло, и мы постараемся как можно быстрее вернуть всё обратно в строй, но, пока проблемы связаны с железом, программисты практически бессильны. Я надеюсь, что компания предпримет меры, чтобы такая ситуация больше не повторялась.
5-10 секунд он не стартует, только потому что у вас, видимо, иерархия объектов не очень большая и сложная. Просто написание use Moose уже увеличивает время запуска почти до секунды (0.6-0.8.). А с большой и… творческой системой объектов, у меня он стартует секунды за две-три на 4-ядерном проце с 8 гектарами. У коллег, которые Moose используют ещё активнее, вроде барьер в 5 секунд уже пройден.
А насчёт Perl6 у меня есть много отдельных, и не очень печатных слов… Тамошние регекспы меня когда-то сломили. :(
Окей, не могу не согласиться с вашими доводами. А насчёт производительности — надо подумать, как можно было бы сравнить Perl и V8. Может быть подобрать какой-то набор полу-математических тестов, которые можно будет относительно быстро реализовать и на Perl и на JS.
Perl 6 я, извините, Perl-ом считать отказываюсь. Даже Python и Ruby имеют с Perl 5 больше общего, чем Perl 6. А вот новая объектная модель (если вы имеете в виду Moose) — это да, это конечно здорово… было бы, если бы оно не так сильно тормозило и не жрало столько памяти.
Впрочем, посмотрим. Я буду искрене рад, если Perl продолжит активно развиваться и совершенствоваться. Допилят интерпретатор, оптимизируют под Moose, чтобы оно не стартовало по 5-10 секунд… :) Может даже VM прикрутят, да тот же Parrot. И станет всем хорошо. :)
Не вижу прямой логической связи. В конце 1940х годов можно было сказать, что человек никогда не летал и не летает в космос. Но следовало ли бы из этого, что никогда и не полетит?..
Все старые решения, типа MS Jscript, Netscape Server страдали большим недостатком. Они были платными и довольно дорогими. А вот то, что в области server-side Javascript появляются новые решения не наводит ли вас на какие-то мысли?
Даже в Mozilla озаботились стандартизацией будущего серверного Javascript, собирая наработки в будущий черновик стандарта: https://wiki.mozilla.org/ServerJS. Конечно, это дело не ближайших двух-трёх лет, но в будущем…
Так что — может быть будет Javascript на серверах, может быть нет… Если бы использовался, это было бы любопытно — хорошо когда есть много разных технологий, и есть из чего выбирать. :)
Да я, собственно, и не спешу — я сам программист на Perl с довольно большим стажем. На пессимистичные мысли в отношении будущего Perl меня наводит то, как он развивался последние 10 лет. И даже то, что происходит сейчас (выпуск 5.10.0, 5.10.1), может лишь отсрочить агонию. Конечно, полностью ( как люди ) языки умирают редко, но несколько сотен человек по всему миру, поддерживающие легаси-приложения погоды уже не сделают.
Javascript на сервере существует ещё раньше, как минимум с 1998 года — была такая штука — Netscape Server. Но это не очень важно, потому что широко Javascript никогда на сервере не применялся и не применяется в настоящий момент.
Затраты могут быть немножко больше и на JS-реализацию. Для того, чтобы сделать рандомные блоки на стороне клиента, вам надо будет отдать клиенту все блоки сразу, да ещё и немного яваскрипта. Ну, или делать ещё, как минимум, один AJAX-запрос на каждую загрузку странички. Это рост числа соединений, и это трафик.
Так что, считайте, что вам дороже — чуть большие затраты CPU и памяти (на SSI), или трафика (на JS). Это не говоря уже о том, что JS может не у всех клиентов работать.
Но, дело в том, что тест я проводил на собственном десктопе, где одновременно была запущена целая KDE, так что воспроизводимость результатов теста оказалась… не на высоте. Я надеюсь, у меня когда-нибудь окажется достаточно свободного времени, чтобы провести это же тест в более подходящих условиях. :)
Нам очень жаль, что это произошло, и мы постараемся как можно быстрее вернуть всё обратно в строй, но, пока проблемы связаны с железом, программисты практически бессильны. Я надеюсь, что компания предпримет меры, чтобы такая ситуация больше не повторялась.
А насчёт Perl6 у меня есть много отдельных, и не очень печатных слов… Тамошние регекспы меня когда-то сломили. :(
Впрочем, посмотрим. Я буду искрене рад, если Perl продолжит активно развиваться и совершенствоваться. Допилят интерпретатор, оптимизируют под Moose, чтобы оно не стартовало по 5-10 секунд… :) Может даже VM прикрутят, да тот же Parrot. И станет всем хорошо. :)
Все старые решения, типа MS Jscript, Netscape Server страдали большим недостатком. Они были платными и довольно дорогими. А вот то, что в области server-side Javascript появляются новые решения не наводит ли вас на какие-то мысли?
Даже в Mozilla озаботились стандартизацией будущего серверного Javascript, собирая наработки в будущий черновик стандарта: https://wiki.mozilla.org/ServerJS. Конечно, это дело не ближайших двух-трёх лет, но в будущем…
Так что — может быть будет Javascript на серверах, может быть нет… Если бы использовался, это было бы любопытно — хорошо когда есть много разных технологий, и есть из чего выбирать. :)
На самом деле, я склонен согласиться, что модулю V8 для nginx вряд ли суждена большая популярность. Однако, персонально мне он интересен. :)
Так что, считайте, что вам дороже — чуть большие затраты CPU и памяти (на SSI), или трафика (на JS). Это не говоря уже о том, что JS может не у всех клиентов работать.