Комментарии 40
А что вы думаете по поводу node.js в качестве быстрого и эффективного решения?
Сравнивать js и С++ с libevent? Если вы под быстрым имеете ввиду скорость разработки, я может еще соглашусь отчасти, но если мы говорим о быстроте работы в highload-проектах, тут даже сравнивать нечего.
А группе разработчиков социальной сети Вконтакте нравится вот.
Я сравнивал скорость выдачи статики nginx c одним воркером и простенького приложения на node.js (тоже одного процесса), разница в производительности была всего в 1.5 раза.
Т.е. при 1000 клиентов можно принять еще 500?
Это всего?
Это дохрена.
Это всего?
Это дохрена.
Это ничтожная плата за гибкость. Perl/python/php работают в 10 раз медленнее С, однако, веб-приложения пишут именно на них
Заблуждаетесь.
www.phpprogrammer.co.nz/speed-test-php-vs-perl-vs-python-vs-go-vs-c
Когда нужен быдлокод и неважно как он будет работать, то плата ничтожна.
Там где нужна скорость 50% производительности это огромный прирост.
Не зря есть HipHop-PHP.
www.phpprogrammer.co.nz/speed-test-php-vs-perl-vs-python-vs-go-vs-c
Когда нужен быдлокод и неважно как он будет работать, то плата ничтожна.
Там где нужна скорость 50% производительности это огромный прирост.
Не зря есть HipHop-PHP.
если внимательно прочесть статью, то там тест на «Hello Word»
на разных задачах — разное соотношение производительности.
Был сервис в инете, который просчитывал производительность одного из выбранных языков для конкретной задачи (было предложено порядка 10 различных задач)
Там соотношение Perl/PHP было где-то одинаково (на одних задачах РНР был быстрее Перла, на иных Перл обгонял пых). А если судить данному тесту, то Perl в 2 раза быстрее РНР.
>Там где нужна скорость 50% производительности это огромный прирост
согл, иначе бы memcached,sphinx и mysql были бы написаны на Перле или РНР
в некоторых проектах экономят на системных вызовах борясь за миллисекунды производительности.
>Не зря есть HipHop-PHP
Не надо забывать что HipHop расчитан под определенный круг задач (проект) и некоторые простые РНР-функции на нем не отрабатывают.
> Perl/python/php работают в 10 раз медленнее С, однако, веб-приложения пишут именно на них
с развитием скриптовых и самого WEB — упростилась его разработка. Если капнуть в историю самого РНР, то порвоночально он появился из набора полезных WEB ориентированных c-функций. С развитием скриптовых языков значительно упростилось программирование. Это в свою очередь не дало развитию сишных библиотек (а их к сожалению так мало) ориентированных конкретно на WEB.
С ростом требований к производительности стали появлятся соответствующие библиоетки и фреймворки.
на разных задачах — разное соотношение производительности.
Был сервис в инете, который просчитывал производительность одного из выбранных языков для конкретной задачи (было предложено порядка 10 различных задач)
Там соотношение Perl/PHP было где-то одинаково (на одних задачах РНР был быстрее Перла, на иных Перл обгонял пых). А если судить данному тесту, то Perl в 2 раза быстрее РНР.
>Там где нужна скорость 50% производительности это огромный прирост
согл, иначе бы memcached,sphinx и mysql были бы написаны на Перле или РНР
в некоторых проектах экономят на системных вызовах борясь за миллисекунды производительности.
>Не зря есть HipHop-PHP
Не надо забывать что HipHop расчитан под определенный круг задач (проект) и некоторые простые РНР-функции на нем не отрабатывают.
> Perl/python/php работают в 10 раз медленнее С, однако, веб-приложения пишут именно на них
с развитием скриптовых и самого WEB — упростилась его разработка. Если капнуть в историю самого РНР, то порвоночально он появился из набора полезных WEB ориентированных c-функций. С развитием скриптовых языков значительно упростилось программирование. Это в свою очередь не дало развитию сишных библиотек (а их к сожалению так мало) ориентированных конкретно на WEB.
С ростом требований к производительности стали появлятся соответствующие библиоетки и фреймворки.
Этот тест бесполезен для сравнения скорости приложений. Он говорит больше о времени старта, чем о чём-либо ещё.
Множество нагруженных приложений (Wikipedia, VKontakte например) не используют HipHop. Однако, мне неизвестно ни об одном крупном веб-приложении целиком написанном на C или другом компилируемом языке.
Множество нагруженных приложений (Wikipedia, VKontakte например) не используют HipHop. Однако, мне неизвестно ни об одном крупном веб-приложении целиком написанном на C или другом компилируемом языке.
Однако, мне неизвестно ни об одном крупном веб-приложении целиком написанном на C или другом компилируемом языке.
а мне известно: ya.ru, google.com
не надо целиком писать весь проект на Си — это утопия (хотя есть такие проекты). На Си пишутся отдельные части, требующие больших вычислений или высокой производительности. Например на РНР не реализуешь модуль расчета трафика и оптимального маршрута (Пробки). Реализовать-то конечно можно, но это будет такой тормоз… что твоим сервисом просто не будут пользоваться.
т.е. и вам неизвестно
что неизвестно? известно:
рефакторил я как-то один америкосовский С++ проект
там БД была на файлах — переделал на мускуль.
Что касается ya.ru & google.com — то они точно на С++
Руководитель Рамблер почты — Андрей Шетухин, меня когда-то консультировал по С++ и в качестве примера поделился исходниками своего фреймворка.
Он реализовал на С++ несколько проектов. Так что, такие проекты есть.
рефакторил я как-то один америкосовский С++ проект
там БД была на файлах — переделал на мускуль.
Что касается ya.ru & google.com — то они точно на С++
Руководитель Рамблер почты — Андрей Шетухин, меня когда-то консультировал по С++ и в качестве примера поделился исходниками своего фреймворка.
Он реализовал на С++ несколько проектов. Так что, такие проекты есть.
Ну с отдачей статики и апач в сущности неплохо справляется, речь конечно же про задачи, активно использующие процессор и память. Думаю, что сравнение будет всегда не в пользу интерпретируемых языков, и не в 1.5 раза. Да и сравнивать стоит потоков этак в 15 тыщ — сколько потянет не сильно напрягаясь сама ОС.
НЛО прилетело и опубликовало эту надпись здесь
как вариант можно было использовать libfcgi
но как я понял — это обертка над cgi скриптом.
хотелось более универсального.
но как я понял — это обертка над cgi скриптом.
хотелось более универсального.
Проблема 1я
При долгой обработке запроса (превышающей таймаут nginx) попытка отправить ответ приводила к выжиранию всей памяти.
Причем четко прослежено что память в цикле отжиралась кусками равными отправляемым.
Решил внутренним таймаутом меньшим чем у nginx.
Что то мне такое решение кажется убогим.
Проблема 2я
При натравливании большого количества входящих через некоторое время получал SIGNAL 13 (broken pipe)
На котором fastcgi цикл у меня дальше хапал 100% процессора и игнорировал все входящие.
Как это отслеживать и лечить я тож не понял.
Ввиду того что процесс один, он сможет использовать ресурсы только одного процессора. Судя по исходникам библиотеки, режим работы с форканьем N потомков после bind() пока не предусмотрен — а жаль
libevent предполагает aio
одновременно вполне тянет 5-ть и более потоков,
на простых скриптах производительность вполне обходит nginx — а стоит бэкэндом,
первоночально было решение с форканьем, тогда в libevent нет необходимости
классическое форканье — это накладные расходы.
одновременно вполне тянет 5-ть и более потоков,
на простых скриптах производительность вполне обходит nginx — а стоит бэкэндом,
первоночально было решение с форканьем, тогда в libevent нет необходимости
классическое форканье — это накладные расходы.
как правило можно просто запускать несколько экземпляров а балансировать на nginx
Я, может чего-то не понимаю, но процессоры грузит обычно не взаимодействие с диском и сетью (где AIO мог бы помочь), а работа самого scgi приложения. Иначе не совсем понятно, зачем было делать именно scgi а не модуль nginx ;) Даже если приложение почти ничего блокирующего не делает, все равно есть некая нагрузка на процессор, и кроме как форком или тредом ее никак не распараллелить по нескольким процессорам. Twisted кстати использует треды для блокирующих операций.
P.S.: Есть положительный опыт добавления форков в сишную программу с libevent, которая в сущности кроме отдачи файлов с диска ничем не занималась, однако при >800 соединений начинала тупить при принятии соединения, да и не только. Результат ввиде графика на сетевом интерфейсе был вполне нагляден (AIO не было ввиду его отсутствия в CentOSёвом ядре)
P.S.: Есть положительный опыт добавления форков в сишную программу с libevent, которая в сущности кроме отдачи файлов с диска ничем не занималась, однако при >800 соединений начинала тупить при принятии соединения, да и не только. Результат ввиде графика на сетевом интерфейсе был вполне нагляден (AIO не было ввиду его отсутствия в CentOSёвом ядре)
некоторые задачи нельзя делать модулем самого nginx по причине его асинхронности. Если по какой-то причине начнется затыкаться сам энджиникс (вернее один их его модулей), а не асинхронный бэкэндовский процесс, то просто все накроется медным тазом. Это хорошо было расписано в докладе Валерия Холодкова.
распараллеливание задачи на треды и процессы имеет смысл при многоядерном процессоре ( более 4х). И то, я считаю если есть такая возможность. При малоядерном процессоре распараллеливание эффективности не даст. Одно ядро всегда будет занято одним WEB процессом, второе — процессом приложения. Если начинаем параллелить процессы приложения, то появляются контексты переключения процессов и прочая кухня для синхронизации. А свободный процессор-то один…
распараллеливание задачи на треды и процессы имеет смысл при многоядерном процессоре ( более 4х). И то, я считаю если есть такая возможность. При малоядерном процессоре распараллеливание эффективности не даст. Одно ядро всегда будет занято одним WEB процессом, второе — процессом приложения. Если начинаем параллелить процессы приложения, то появляются контексты переключения процессов и прочая кухня для синхронизации. А свободный процессор-то один…
Ну времена серверных процессоров с одним ядром и гипертредингом, я надеюсь, прошли несколько лет назад :) И если есть реальный хайлоад, то ставится сервер с двумя процами по 4 ядра — тут явно есть куда параллелиться как раз в случае блокирующих операций, которые, как правильно подмечено, никак нельзя реализовывать как модуль nginx
А на WebSockets это реально?
Или это из пушки по воробьям?
Или это из пушки по воробьям?
WebSockets это из другой оперы: звено WEB-клиент — WEB-сервер
В данном случае идет речь о звене: WEB-сервер — Пользовательское WEB-приложение
.
В данном случае идет речь о звене: WEB-сервер — Пользовательское WEB-приложение
.
Хм, я думал WebSocket это новая технология для замены cgi как такового.
нет, это совсем другое — habrahabr.ru/blogs/webdev/79038/
думаю что scgi и WebSockets немного не совместимы,
хотя если подпилить модуль на анализ соответствующих заголовков — то можно реализовать Websockets
но мое мнение — реализация WebSockets должна быть встроена в WEB-сервер, и web-сервер должен как-то проксировать сокетное соединение на сервер-приложений.
хотя если подпилить модуль на анализ соответствующих заголовков — то можно реализовать Websockets
но мое мнение — реализация WebSockets должна быть встроена в WEB-сервер, и web-сервер должен как-то проксировать сокетное соединение на сервер-приложений.
Асинхронный сервер в качестве бэкенда к асинхронному серверу? Зачем 0_o?
а что конкретно не подходит?
Ну мне кажется очень редко когда такой подход оправдан. Если только Nginx еще кучу всего обслуживает помимо данного бэкенда. Да и то можно ваш сервер переписать с scgi на http и повесить на отдельный порт сервера. Либо написать модуль Nginx и запускать чуть больше воркеров, если сервер не очень сложный.
Меня смущает что как в Nginx так и в вашем сервере при появлении медленной операции все заблокируется и запросы не будут обрабатываться.
Меня смущает что как в Nginx так и в вашем сервере при появлении медленной операции все заблокируется и запросы не будут обрабатываться.
А, кстати, есть ли у scgi преимущества перед http? В том смысле, что можно ведь использовать не scgi_pass а proxy_pass и работать со знакомым протоколом.
> Если только Nginx еще кучу всего обслуживает помимо данного бэкенда
так оно и есть — этот бэкэнд лишь капля в море.
>Да и то можно ваш сервер переписать с scgi на http и повесить на отдельный порт сервера.
есть у меня похожее решение, реализовано как http сервер, который стоит бэкендом к nginx
>Меня смущает что как в Nginx так и в вашем сервере при появлении медленной операции все заблокируется и запросы не будут обрабатываться
при появлении блокирующей операции (не требующей процессорного времени, например ожидание ввода от сервера БД), при поступлении нового запроса просто откроется другой поток и будет обрабатываться. вот интересная ветка habrahabr.ru/blogs/hi/111587/#comment_3561540
так оно и есть — этот бэкэнд лишь капля в море.
>Да и то можно ваш сервер переписать с scgi на http и повесить на отдельный порт сервера.
есть у меня похожее решение, реализовано как http сервер, который стоит бэкендом к nginx
>Меня смущает что как в Nginx так и в вашем сервере при появлении медленной операции все заблокируется и запросы не будут обрабатываться
при появлении блокирующей операции (не требующей процессорного времени, например ожидание ввода от сервера БД), при поступлении нового запроса просто откроется другой поток и будет обрабатываться. вот интересная ветка habrahabr.ru/blogs/hi/111587/#comment_3561540
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
libscgi — эффективное решение для простых и быстрых скриптов