Comments 67
Решения на ерланге убойно стабильные и широкомаштабируемые.
Почему веб асоциируют с РНР? Даже тот-же MochiWeb давал бы довольно сногшибательные результаты.
И по скорости ерланг правит балом. А моменты с высоким объёмом вычислений можно укрощать драйверами на С и Сuda плюшками.
Почему веб асоциируют с РНР? Даже тот-же MochiWeb давал бы довольно сногшибательные результаты.
И по скорости ерланг правит балом. А моменты с высоким объёмом вычислений можно укрощать драйверами на С и Сuda плюшками.
+6
Хм. А можно пруф линки на убойность эрланга? А то что-то не верится что он такой не сшибаемый.
-4
Он изначально проектировался для работы в телекоммуникациях, т.е. аптайм 24/7 и восстановление после сбоев. Чего стоит хотя бы возможность обновления кода без остановки приложения.
Это вам не шаблонизатор на перле, выросший в недоязычок, который умирает от неаккуратных floatval().
Это вам не шаблонизатор на перле, выросший в недоязычок, который умирает от неаккуратных floatval().
+6
Давайте не будем разводить холивары по поводу PHP.
0
Ок :)
0
Я вообще против холиваров. Но Ерорланг — святое.
Тут нужно винить не кривых разрабов РНР где от версии до версии… багофиксы размножают багоюзеров. А с точностью до наоборот: багоюзеров которые стают разрабами…
Ой о чём это я? Ах да терминаторы такие терминаторы =D
— Self! shutdown
Так вот… Виной всему большое количество недописей как софтварных так и суто учебных.
С++ тож может быть обработан лучами поноса. Сайты через CGI можно писать и на АСМе, но ведь это не панацения. Исходить нужно из того что есть ибо временных ресурсов на перепись всей неписи у нас нет: есть девушки, жёны, дети, племянники и прочиегадорадости жизни.
Но из всех зол нужно выбирать самоезлое безопасное и меньшее.
Пока Я выбираю ерорланг.
Тут нужно винить не кривых разрабов РНР где от версии до версии… багофиксы размножают багоюзеров. А с точностью до наоборот: багоюзеров которые стают разрабами…
Ой о чём это я? Ах да терминаторы такие терминаторы =D
— Self! shutdown
Так вот… Виной всему большое количество недописей как софтварных так и суто учебных.
С++ тож может быть обработан лучами поноса. Сайты через CGI можно писать и на АСМе, но ведь это не панацения. Исходить нужно из того что есть ибо временных ресурсов на перепись всей неписи у нас нет: есть девушки, жёны, дети, племянники и прочие
Но из всех зол нужно выбирать самое
Пока Я выбираю ерорланг.
+2
На сколько я помню баго-история веб-сервера yaws насчитывает
одну неправильную обработку http заголовка которой можно его доснуть.
На этом список багов/уязвимостей закончивается.
Bообще взломов ерорланга я ещё не видел. Тем более что это банкоориентированое програмирование, а не какой нибудь уберглюк.
одну неправильную обработку http заголовка которой можно его доснуть.
На этом список багов/уязвимостей закончивается.
Bообще взломов ерорланга я ещё не видел. Тем более что это банкоориентированое програмирование, а не какой нибудь уберглюк.
+1
erlang не быстрый, это раз, а два — это функциональный язык программирования, порог вхождения крайне высок, а php-стал таким распространённым из-за легкости освоения.
-1
Когда речь идет о веб-приложениях, высоконагруженных сервисах или Realtime Web (WebSockets) то про порог вхождения можно забыть. Это задачи другого уровня и для их решения PHP просто не подходит. А если вы вспомните о масштабирование, то Эрланг вне конкуренции.
Если нужно «бложик» сделать или подобное — то PHP вполне уместен. Поэтому он и рулит, т.к. таких задач большенство.
Если нужно «бложик» сделать или подобное — то PHP вполне уместен. Поэтому он и рулит, т.к. таких задач большенство.
+3
Мой комментарий ответ на вопрос о том почему вэб ассоциируется с php.
Насчет высоконагруженных сервисах всегда можно поспорить, и многие будут несогласны. Фактически facebook использует php, Google – python и java (бля высоконагруженных), MS – aspx. Использование erlang ограничено im-приложениями, телекоммуникационными программами и каркасами для распределенной обработки данных. А «бложок» можно и на erlang'е написать, использую тот же nitrogen web framework.
Насчет высоконагруженных сервисах всегда можно поспорить, и многие будут несогласны. Фактически facebook использует php, Google – python и java (бля высоконагруженных), MS – aspx. Использование erlang ограничено im-приложениями, телекоммуникационными программами и каркасами для распределенной обработки данных. А «бложок» можно и на erlang'е написать, использую тот же nitrogen web framework.
+1
бля такие высоконагруженные… с кем не бывает
Вы не пишете сайты на асме? тогда мы идём к вам =D
Я не спорю что можно писать высоконагруз на чём угодно.
Чем большей популярностью пользуются баранки тем более отлажено будет вестись их накрутка и выпечка. Но вот если находятся баранки в шоколаде то никто сначала не обратит на них внимания ибо никто не привык к ним. Потом кто-то попробует их с молоком
— Если софт используется — под него пекутся баранки к чаю. Если нет — то всё печально.
ерорланг недопеченая во многих отношениях шеколадная баранка к которой никто не превык.
— aspx python это конечно хорошо но объём апаратного обеспечения на постройку инфраструктуры может быть выше чем у других решений. И вообще нормальной оценки соотношения ПЗ-количество серваков-количество запросов(клиентов) я не видел.
Так же как и нормальные оценки мифической производительности програм — TLBmiss Когерентности кеша и проч. прелести жизни довольно randomны.
Вы не пишете сайты на асме? тогда мы идём к вам =D
Я не спорю что можно писать высоконагруз на чём угодно.
Чем большей популярностью пользуются баранки тем более отлажено будет вестись их накрутка и выпечка. Но вот если находятся баранки в шоколаде то никто сначала не обратит на них внимания ибо никто не привык к ним. Потом кто-то попробует их с молоком
— Если софт используется — под него пекутся баранки к чаю. Если нет — то всё печально.
ерорланг недопеченая во многих отношениях шеколадная баранка к которой никто не превык.
— aspx python это конечно хорошо но объём апаратного обеспечения на постройку инфраструктуры может быть выше чем у других решений. И вообще нормальной оценки соотношения ПЗ-количество серваков-количество запросов(клиентов) я не видел.
Так же как и нормальные оценки мифической производительности програм — TLBmiss Когерентности кеша и проч. прелести жизни довольно randomны.
-1
facebook использует php только там, где исторически сложилось, ну и как шаблонизатор. Разные его части написаны на различных языках-технологиях.
google практически отказался от python, использует его только для прототипирования. unladen swallow забросили уже, что о чем-то говорит. Да и кроме java, там даже С++ не чураются (вроде какбы бекенд Okrut на нем)
Так как сейчас все больше веб приложения становятся realtime, то начинаются поиски адекватного решения и новых-старых технологий. Думаю erlang вполне подходит для таких новых требований к веб-приложениям. Уж точно лучше чем php.
Просто для такого уровня приложений — легкость освоения или порог вхождения не играет роли. Спецы найдутся.
google практически отказался от python, использует его только для прототипирования. unladen swallow забросили уже, что о чем-то говорит. Да и кроме java, там даже С++ не чураются (вроде какбы бекенд Okrut на нем)
Так как сейчас все больше веб приложения становятся realtime, то начинаются поиски адекватного решения и новых-старых технологий. Думаю erlang вполне подходит для таких новых требований к веб-приложениям. Уж точно лучше чем php.
Просто для такого уровня приложений — легкость освоения или порог вхождения не играет роли. Спецы найдутся.
+4
Осмелюсь поделиться личным опытом. Для меня время вхождения в Erlang составило месяц. За это время было прочитано произведение Джо Армстронга и прокурено определенное число публикаций во всемирной паутине. По истечению этого времени я смог писать код промышленного уровня. Процесс перестраивания мозгов на функциональщину доставил кучу удовольствия.
Насколько я знаю это не исключение. Erlang очень легкий для обучения язык. Вот только осознаешь это только когда уже взялся за дело.
Насколько я знаю это не исключение. Erlang очень легкий для обучения язык. Вот только осознаешь это только когда уже взялся за дело.
+3
Пока документация на особо извращенные (то бишь интересные) функции нагоняет страх :) Я принялся изучать erlang года два назад, тогда не особо пошло, но периодически возвращаюсь к нему. Особенно досадно, что мало достойных примеров, так что вам большое спасибо!:)
0
Приступая к изучению ерланга надо уже знать, что на нём делать, т.е. быть знакомым с проблемной областью. Иначе, изучая его на стандартных примерах с фибоначчами и факториалами, собственно, Erlang/OTP и не изучишь.
+1
Правильные книжки как раз и вводят правильно в предметную область. Насколько я знаю, в этом мире существует ровно 2 (почти одинаковые) книги про непосредственно сам язык (ну и OTP, ибо без него не воспринимается). Армстронга не читал, а сам пользуюсь трудом Франческо Цезарини. Очень грамотно подводит к проблеме, показывает ее и объясняет решение. И примеры не абстрактные факториалы, а какие-то зачатки систем распределения частот, телефонов и подобные. В общем, удивительно, что до сих пор язык в жопе (ну, сравнительной, конечно). Хотя, может оно и к лучшему.
+2
В большинстве случаев он просто не нужен, либо как из пушки по воробьям.
-2
Давайте, все-таки, по существу. Erlang хорош там, где он хорош (хайлоад, concurrency, отказоустойчивость). Зачем его применять там, где он не хорош? Ну давайте вы пожалуетесь, что трактора не нужны, потому что феррари их обгоняет, а огород вы и лопатой вскопаете.
0
Разве похоже, что я жалуюсь? У меня уже три года ерланг — основной язык, процентов 95 пишу на нём. Главное, не считать его языком общего назначения и не притягивать туда, куда не надо.
+1
Сам язык вообще довольно простой. Но есть еще платформа OTP со стандартными модулями типа диспетчеров/серверов etc и стандартами создания приложений на Erlang. После того как с синтаксисом и основами разберешься, нужно обязательно OTP поковырять.
0
Ерланг называют «PHP из мира ФП» как раз за очень низкий порог вхождения. Так что миф о том, что он очень сложен, порождён исключительно предрассудками.
+3
>Это было первой попыткой. 45 Кб для каждого подключения кажутся довольно большими – вероятно, можно собрать что-нибудь на C, использующем libevent, который мог проделать похожее, затратив допустим 4.5Кб для каждого подключения (это только предположение, если у кого-либо есть подобный опыт, пожалуйста, оставьте комментарий).
groovy++ потребляет 2.5G на 512к соединений, т.е. около 5к на соединение:
groovy.dzone.com/articles/512000-concurrent-websockets
а ведь при всём при этом ведь groovy — далеко не c/c++ и даже не Java…
groovy++ потребляет 2.5G на 512к соединений, т.е. около 5к на соединение:
groovy.dzone.com/articles/512000-concurrent-websockets
а ведь при всём при этом ведь groovy — далеко не c/c++ и даже не Java…
+1
Я не хочу раскрывать все карты сразу :)
Если Вам не терпится, можете взглянуть на часть 3 в оригинале.
Если Вам не терпится, можете взглянуть на часть 3 в оригинале.
0
уже — прогрыш всё равно остался гигантский
0
У меня нету большого желания спорить насчет такой небольшой разницы. Но все же.
Из вашей ссылки:
>2.5GB memory was used by Java heap (around 5K per connection but of course not including kernel structures).
На Erlang в результате получилось 2Кб на каждое соединение.
Я не знаю куда вы смотрели, когда нашли «гигантский проигрыш», да и «проигрыш» вообще.
Из вашей ссылки:
>2.5GB memory was used by Java heap (around 5K per connection but of course not including kernel structures).
На Erlang в результате получилось 2Кб на каждое соединение.
Я не знаю куда вы смотрели, когда нашли «гигантский проигрыш», да и «проигрыш» вообще.
+1
>Я не знаю куда вы смотрели, когда нашли «гигантский проигрыш», да и «проигрыш» вообще.
1) 2k — только при использовании libevent+C, на не совсем чистом (т.е. с hibernate) erlang'е «In other words, you need to allow 40KB per connection.», т.е. 8x проигрыш
I connected 1M clients to the httpdcnode server using the same client as above, the machine showed a total of just under 10GB or memory used. The resident memory of the server process was stable at under 2GB
не уверен, что тут можно считать только 2GB и «забыть» про остальные 10…
1) 2k — только при использовании libevent+C, на не совсем чистом (т.е. с hibernate) erlang'е «In other words, you need to allow 40KB per connection.», т.е. 8x проигрыш
I connected 1M clients to the httpdcnode server using the same client as above, the machine showed a total of just under 10GB or memory used. The resident memory of the server process was stable at under 2GB
не уверен, что тут можно считать только 2GB и «забыть» про остальные 10…
0
В Вашем примере автор какраз «забыл» про расходы ядра:
> around 5K per connection but of course not including kernel structures
Почему же в случае с Erlang их нужно считать?
> around 5K per connection but of course not including kernel structures
Почему же в случае с Erlang их нужно считать?
0
>В Вашем примере автор какраз «забыл» про расходы ядра
точных данных, увы, нет, но есть все основания полагать, что они меньше 10G/2 libevent'а. Можно попробовать повторить эксперимент и оценить накладные расходы
точных данных, увы, нет, но есть все основания полагать, что они меньше 10G/2 libevent'а. Можно попробовать повторить эксперимент и оценить накладные расходы
-1
Или я Вас не правильно понял, или Вы «имеете все основания полагать», что в случае с Groovy у ядра другие порты и потребление памяти?
Erlang: 2Kb + kernel
Groovy: 5Kb + kernel
Я удивлен, что эта ветка спора на пустом месте достигла такой глубины.
Erlang: 2Kb + kernel
Groovy: 5Kb + kernel
Я удивлен, что эта ветка спора на пустом месте достигла такой глубины.
+1
Боюсь сравнение с groovy в данном случае не корректно. В вашем примере использовался non blocking evented сервер. Подозреваю, что при такой архитектуре все соединения обрабатываются одним покотом и нам тупо нехватит CPU.
Можно ли этот groovy++ сервер запустить на 16ядрах без необходимости дополнительно синхронизировать доступ к общим данным, например, списку открытых сокетов?
В случае с erlang можно запустить хоть на 160 ядрах всех 10 машин кластера.
Можно ли этот groovy++ сервер запустить на 16ядрах без необходимости дополнительно синхронизировать доступ к общим данным, например, списку открытых сокетов?
В случае с erlang можно запустить хоть на 160 ядрах всех 10 машин кластера.
0
>нам тупо нехватит CPU.
если внимательно прочитать текст по ссылке, то можно увидеть, что на 512k сообщений уходит не более 30% от «m1.large» Amazon EC2 (2 virtual cores)
>Можно ли этот groovy++ сервер запустить на 16ядрах без необходимости дополнительно синхронизировать доступ к общим данным, например, списку открытых сокетов?
он сам автоматом использует все доступные ядра в пределах одной машины. кластеризуемость на разных машинах — надо смотреть www.jboss.org/netty.html
>В случае с erlang можно запустить хоть на 160 ядрах всех 10 машин кластера.
а сколько будет оверхед от шаринга каких-либо данных на эти 10 машин?
если внимательно прочитать текст по ссылке, то можно увидеть, что на 512k сообщений уходит не более 30% от «m1.large» Amazon EC2 (2 virtual cores)
>Можно ли этот groovy++ сервер запустить на 16ядрах без необходимости дополнительно синхронизировать доступ к общим данным, например, списку открытых сокетов?
он сам автоматом использует все доступные ядра в пределах одной машины. кластеризуемость на разных машинах — надо смотреть www.jboss.org/netty.html
>В случае с erlang можно запустить хоть на 160 ядрах всех 10 машин кластера.
а сколько будет оверхед от шаринга каких-либо данных на эти 10 машин?
0
Вы не поняли, что Вам хотел сказать товарищ insa. С тем, что приложение на Groovy можно распараллелить никто не спорит.
Но в случае с Erlang это просто и эффективно. Правильный код на Erlang имеет практически линейный рост производительности от числа ядер.
Неблокирующая параллельность это прекрасно.
Но к конкретной задаче CPU не имеет никакого отношения.
Но в случае с Erlang это просто и эффективно. Правильный код на Erlang имеет практически линейный рост производительности от числа ядер.
Неблокирующая параллельность это прекрасно.
Но к конкретной задаче CPU не имеет никакого отношения.
+1
>Но в случае с Erlang это просто и эффективно.
если говорить исключительно о сабжевом примере — groovy не только не уступает, но и даже выигрывает в простоте
>Но к конкретной задаче CPU не имеет никакого отношения.
ну так это и не я начал говорить про CPU, я говорил только о сравнении потребляемой памяти на сабжевом примере-задаче
если говорить исключительно о сабжевом примере — groovy не только не уступает, но и даже выигрывает в простоте
>Но к конкретной задаче CPU не имеет никакого отношения.
ну так это и не я начал говорить про CPU, я говорил только о сравнении потребляемой памяти на сабжевом примере-задаче
0
> он сам автоматом использует все доступные ядра в пределах одной машины.
Ну, это круто :) Побольше бы таких платформ.
> а сколько будет оверхед от шаринга каких-либо данных на эти 10 машин?
Это скорее зависит от данных, чем от языка программирования. Шарить информацию о 512к открытых соединениях — это вообще не проблема.
Ну, это круто :) Побольше бы таких платформ.
> а сколько будет оверхед от шаринга каких-либо данных на эти 10 машин?
Это скорее зависит от данных, чем от языка программирования. Шарить информацию о 512к открытых соединениях — это вообще не проблема.
0
Еще по поводу неблокирующего сервера…
Если я в этом Gretty сделаю медленный блокирующий запрос, скажем, к мускулю, то это заблокирует весь сервер? Сможет ли сервер принимать и обрабатывать соединения в это время?
Если я в этом Gretty сделаю медленный блокирующий запрос, скажем, к мускулю, то это заблокирует весь сервер? Сможет ли сервер принимать и обрабатывать соединения в это время?
0
>Сможет ли сервер принимать и обрабатывать соединения в это время?
конечно. а разве бывают такие сервера, которые не смогут?
конечно. а разве бывают такие сервера, которые не смогут?
-1
Да любой основанный на select/epool/kqueue сервер.
Допустим если я напишу модуль для Nginx который будет медленно запрашивать данные из MySQL через стандартный libmysql для каждого HTTP запроса. Такой сервер с того момента как я выполню mysql_query и до возврата из этой функции не сможет принять/обработать ни одного запроса (ну, с точностью до колличества воркеров нгинкса, которых обычно мало)
Видимо NodeJS, если использовать недоработанный биндинг к MySQL.
Допустим если я напишу модуль для Nginx который будет медленно запрашивать данные из MySQL через стандартный libmysql для каждого HTTP запроса. Такой сервер с того момента как я выполню mysql_query и до возврата из этой функции не сможет принять/обработать ни одного запроса (ну, с точностью до колличества воркеров нгинкса, которых обычно мало)
Видимо NodeJS, если использовать недоработанный биндинг к MySQL.
+1
Если брать в расчёт «стандартный» tomcat, то он тоже ограничен количеством воркеров (а точнее одновременных коннектов), но во-первых их штук 200 по-умолчанию, а во-вторых они друг от друга явно не зависят (хранение сессий в расчёт не принимаем).
Если говорить про коннекты к БД, то они пулятся и друг от друга тоже не зависят.
В вашем случае, я так понимаю, получается что mysql-connector однопоточный что ли?
Если говорить про коннекты к БД, то они пулятся и друг от друга тоже не зависят.
В вашем случае, я так понимаю, получается что mysql-connector однопоточный что ли?
0
c Tomcat-ом не сталкивался, но что то мне подсказывает, что он многопоточный/многопроцессный. Это вообще из другой песочницы, такие больше 1000 одновременных соединений уже вряд ли переживут.
C пуллингом соединений другая проблема — для каждого запроса нужно писать callback и, желательно, errback, что довольно неудобно и код становится нечитаемым если запросов много.
А в erlang можно без особых проблем создавать сколько хошь эрланговских микропроцессов (обычно по одному на соединение как в Apache etc) и в каждом из них делать любые блокирующие действия. Хошь файл с диска считывай, хошь 10 последовательных запросов к мускулю делай как в PHP, хошь с удаленного сервера данные запрашивай, хошь sleep(100) делай. При этом сервер будет продолжать принимать соединения как ни в чем не бывало. И микропроцессов таких можно создать очень много — по количеству одновременно открытых соединений приближается к асинхронным серверам.
И тут имеются преимущества как много-поточных/процессных серверов (Апач etc) в том, что обработка одного запроса никак не влияет на другие, так и преимущества асинхронных серверов (Node.JS, Tornado) в том, что может обрабатывать огромное число соединений.
C пуллингом соединений другая проблема — для каждого запроса нужно писать callback и, желательно, errback, что довольно неудобно и код становится нечитаемым если запросов много.
А в erlang можно без особых проблем создавать сколько хошь эрланговских микропроцессов (обычно по одному на соединение как в Apache etc) и в каждом из них делать любые блокирующие действия. Хошь файл с диска считывай, хошь 10 последовательных запросов к мускулю делай как в PHP, хошь с удаленного сервера данные запрашивай, хошь sleep(100) делай. При этом сервер будет продолжать принимать соединения как ни в чем не бывало. И микропроцессов таких можно создать очень много — по количеству одновременно открытых соединений приближается к асинхронным серверам.
И тут имеются преимущества как много-поточных/процессных серверов (Апач etc) в том, что обработка одного запроса никак не влияет на другие, так и преимущества асинхронных серверов (Node.JS, Tornado) в том, что может обрабатывать огромное число соединений.
+1
хм, что-то вы меня совсем запутали…
вот пришёл нам запрос, пусть это будет GET /someurl, как будет отличаться его обработка в случае erlang'а и в случае tomcat'а?
вот пришёл нам запрос, пусть это будет GET /someurl, как будет отличаться его обработка в случае erlang'а и в случае tomcat'а?
0
Я правда не знаю как работает томкат, не сталкивался. Возьму для примера Apache в prefork режиме.
В случае апача, насколько я представляю, стартует главный процесс апача, запускает, допустим, 100 воркеров, подключается к их stdin/stdout/stderr, начинает слушать 80-й порт. Приходит запрос — апач как то передает его одному из воркеров, тот его обрабатывает, причем может обрабатывать как угодно, делать медленные запросы к БД, конвертировать картинки [в это время могут приходить еще запросы, главный процесс будет их принимать и сразу отдавать воркерам — пока не закончатся все свободные воркеры или вся память на сервере т.к. процесс апача занимает под 15Мб] и как то возвращает результат. И если во время обработки воркер почему то упадет, то это не повлияет ни на остальные обрабатываемые запросы ни на главный процесс апача. Просто на этот один запрос вернется 500 и главный процесс перезапустит упавшего воркера.
Какая тут проблема? Она в общем-то одна — нельзя создать 10 000 воркеров апача — либо закончится память либо ОС начнет тормозить.
Как работает веб-сервер на эрланге — ТОЧНО ТАК ЖЕ (правда обычно новые микропроцессы запускаются не заранее а при подключении нового клиента). Тогда в чем разница? В том что апач на каждого клиента тратит 15-20Мб памяти (воркер апача) а Erlang 2-10кб (микропроцесс erlang). Так что веб сервер на Erlang может обрабатывать гораздо больше одновременных соединений (если конечно обработка не завязана на CPU, если да — то пофиг чем обрабатывать).
В случае апача, насколько я представляю, стартует главный процесс апача, запускает, допустим, 100 воркеров, подключается к их stdin/stdout/stderr, начинает слушать 80-й порт. Приходит запрос — апач как то передает его одному из воркеров, тот его обрабатывает, причем может обрабатывать как угодно, делать медленные запросы к БД, конвертировать картинки [в это время могут приходить еще запросы, главный процесс будет их принимать и сразу отдавать воркерам — пока не закончатся все свободные воркеры или вся память на сервере т.к. процесс апача занимает под 15Мб] и как то возвращает результат. И если во время обработки воркер почему то упадет, то это не повлияет ни на остальные обрабатываемые запросы ни на главный процесс апача. Просто на этот один запрос вернется 500 и главный процесс перезапустит упавшего воркера.
Какая тут проблема? Она в общем-то одна — нельзя создать 10 000 воркеров апача — либо закончится память либо ОС начнет тормозить.
Как работает веб-сервер на эрланге — ТОЧНО ТАК ЖЕ (правда обычно новые микропроцессы запускаются не заранее а при подключении нового клиента). Тогда в чем разница? В том что апач на каждого клиента тратит 15-20Мб памяти (воркер апача) а Erlang 2-10кб (микропроцесс erlang). Так что веб сервер на Erlang может обрабатывать гораздо больше одновременных соединений (если конечно обработка не завязана на CPU, если да — то пофиг чем обрабатывать).
+1
Java NIO значительно легковеснее врача и может держать сотни тысяч соединений, см, например, blog.urbanairship.com/blog/2010/08/24/c500k-in-action-at-urban-airship/
-1
Что то мне кажется мы входим в рекурсию. Я с Java не знаком, но, как я понял, в статье по вашей ссылке асинхронный сервер… Тут недавно статья появилась habrahabr.ru/blogs/webdev/111357/ там разница более менее понятно описана.
//Минусы не мои
//Минусы не мои
0
Из питоньих Tornado так же не сможет. Twisted не сможет, но там есть возможность довольно просто использовать пулл соединений с БД
0
Можно поподробнее почему такие настройки sysctl?
0
error: «net.ipv4.netfilter.ip_conntrack_max» is an unknown key
((((
вот на это ругнулось net.ipv4.netfilter.ip_conntrack_max
((((
вот на это ругнулось net.ipv4.netfilter.ip_conntrack_max
0
Реально ли такой финт ушами сделать в Windows? Как я понимаю, для этого требуется возможность изменения сетевых параметров по аналогии с sysctl. Может кто-то делал подобные настройки в Win?
0
ИМХО В Windows такие финты могут не пройти.
0
Вообще финт с sysctl больше нужен для клиента, для сервера можно на них забить, если только для тестов.
0
Жаль, что перевод появился тут спустя почти два с половиной года после оригинала. Спасибо, интересная, и по-прежнему актуальная ретроспектива.
0
Sign up to leave a comment.
Comet–приложение для Mochiweb c нагрузкой в 1 000 000 пользователей. Часть 1/3