Комментарии 67
Решения на ерланге убойно стабильные и широкомаштабируемые.
Почему веб асоциируют с РНР? Даже тот-же MochiWeb давал бы довольно сногшибательные результаты.
И по скорости ерланг правит балом. А моменты с высоким объёмом вычислений можно укрощать драйверами на С и Сuda плюшками.
Почему веб асоциируют с РНР? Даже тот-же MochiWeb давал бы довольно сногшибательные результаты.
И по скорости ерланг правит балом. А моменты с высоким объёмом вычислений можно укрощать драйверами на С и Сuda плюшками.
Хм. А можно пруф линки на убойность эрланга? А то что-то не верится что он такой не сшибаемый.
Он изначально проектировался для работы в телекоммуникациях, т.е. аптайм 24/7 и восстановление после сбоев. Чего стоит хотя бы возможность обновления кода без остановки приложения.
Это вам не шаблонизатор на перле, выросший в недоязычок, который умирает от неаккуратных floatval().
Это вам не шаблонизатор на перле, выросший в недоязычок, который умирает от неаккуратных floatval().
Давайте не будем разводить холивары по поводу PHP.
Ок :)
Я вообще против холиваров. Но Ерорланг — святое.
Тут нужно винить не кривых разрабов РНР где от версии до версии… багофиксы размножают багоюзеров. А с точностью до наоборот: багоюзеров которые стают разрабами…
Ой о чём это я? Ах да терминаторы такие терминаторы =D
— Self! shutdown
Так вот… Виной всему большое количество недописей как софтварных так и суто учебных.
С++ тож может быть обработан лучами поноса. Сайты через CGI можно писать и на АСМе, но ведь это не панацения. Исходить нужно из того что есть ибо временных ресурсов на перепись всей неписи у нас нет: есть девушки, жёны, дети, племянники и прочиегадорадости жизни.
Но из всех зол нужно выбирать самоезлое безопасное и меньшее.
Пока Я выбираю ерорланг.
Тут нужно винить не кривых разрабов РНР где от версии до версии… багофиксы размножают багоюзеров. А с точностью до наоборот: багоюзеров которые стают разрабами…
Ой о чём это я? Ах да терминаторы такие терминаторы =D
— Self! shutdown
Так вот… Виной всему большое количество недописей как софтварных так и суто учебных.
С++ тож может быть обработан лучами поноса. Сайты через CGI можно писать и на АСМе, но ведь это не панацения. Исходить нужно из того что есть ибо временных ресурсов на перепись всей неписи у нас нет: есть девушки, жёны, дети, племянники и прочие
Но из всех зол нужно выбирать самое
Пока Я выбираю ерорланг.
На сколько я помню баго-история веб-сервера yaws насчитывает
одну неправильную обработку http заголовка которой можно его доснуть.
На этом список багов/уязвимостей закончивается.
Bообще взломов ерорланга я ещё не видел. Тем более что это банкоориентированое програмирование, а не какой нибудь уберглюк.
одну неправильную обработку http заголовка которой можно его доснуть.
На этом список багов/уязвимостей закончивается.
Bообще взломов ерорланга я ещё не видел. Тем более что это банкоориентированое програмирование, а не какой нибудь уберглюк.
erlang не быстрый, это раз, а два — это функциональный язык программирования, порог вхождения крайне высок, а php-стал таким распространённым из-за легкости освоения.
Когда речь идет о веб-приложениях, высоконагруженных сервисах или Realtime Web (WebSockets) то про порог вхождения можно забыть. Это задачи другого уровня и для их решения PHP просто не подходит. А если вы вспомните о масштабирование, то Эрланг вне конкуренции.
Если нужно «бложик» сделать или подобное — то PHP вполне уместен. Поэтому он и рулит, т.к. таких задач большенство.
Если нужно «бложик» сделать или подобное — то PHP вполне уместен. Поэтому он и рулит, т.к. таких задач большенство.
Мой комментарий ответ на вопрос о том почему вэб ассоциируется с 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.
бля такие высоконагруженные… с кем не бывает
Вы не пишете сайты на асме? тогда мы идём к вам =D
Я не спорю что можно писать высоконагруз на чём угодно.
Чем большей популярностью пользуются баранки тем более отлажено будет вестись их накрутка и выпечка. Но вот если находятся баранки в шоколаде то никто сначала не обратит на них внимания ибо никто не привык к ним. Потом кто-то попробует их с молоком
— Если софт используется — под него пекутся баранки к чаю. Если нет — то всё печально.
ерорланг недопеченая во многих отношениях шеколадная баранка к которой никто не превык.
— aspx python это конечно хорошо но объём апаратного обеспечения на постройку инфраструктуры может быть выше чем у других решений. И вообще нормальной оценки соотношения ПЗ-количество серваков-количество запросов(клиентов) я не видел.
Так же как и нормальные оценки мифической производительности програм — TLBmiss Когерентности кеша и проч. прелести жизни довольно randomны.
Вы не пишете сайты на асме? тогда мы идём к вам =D
Я не спорю что можно писать высоконагруз на чём угодно.
Чем большей популярностью пользуются баранки тем более отлажено будет вестись их накрутка и выпечка. Но вот если находятся баранки в шоколаде то никто сначала не обратит на них внимания ибо никто не привык к ним. Потом кто-то попробует их с молоком
— Если софт используется — под него пекутся баранки к чаю. Если нет — то всё печально.
ерорланг недопеченая во многих отношениях шеколадная баранка к которой никто не превык.
— aspx python это конечно хорошо но объём апаратного обеспечения на постройку инфраструктуры может быть выше чем у других решений. И вообще нормальной оценки соотношения ПЗ-количество серваков-количество запросов(клиентов) я не видел.
Так же как и нормальные оценки мифической производительности програм — TLBmiss Когерентности кеша и проч. прелести жизни довольно randomны.
facebook использует php только там, где исторически сложилось, ну и как шаблонизатор. Разные его части написаны на различных языках-технологиях.
google практически отказался от python, использует его только для прототипирования. unladen swallow забросили уже, что о чем-то говорит. Да и кроме java, там даже С++ не чураются (вроде какбы бекенд Okrut на нем)
Так как сейчас все больше веб приложения становятся realtime, то начинаются поиски адекватного решения и новых-старых технологий. Думаю erlang вполне подходит для таких новых требований к веб-приложениям. Уж точно лучше чем php.
Просто для такого уровня приложений — легкость освоения или порог вхождения не играет роли. Спецы найдутся.
google практически отказался от python, использует его только для прототипирования. unladen swallow забросили уже, что о чем-то говорит. Да и кроме java, там даже С++ не чураются (вроде какбы бекенд Okrut на нем)
Так как сейчас все больше веб приложения становятся realtime, то начинаются поиски адекватного решения и новых-старых технологий. Думаю erlang вполне подходит для таких новых требований к веб-приложениям. Уж точно лучше чем php.
Просто для такого уровня приложений — легкость освоения или порог вхождения не играет роли. Спецы найдутся.
Ерорланг правит балом в вебе.
По поводу быстроты всё зависит от количества создаваемых объектов, тоесть прямоты рук.
А вот с точки зрения доступности и маштабируемости спору нет.
На ФП перепилить/допилить мозг можно быстро, благо уже были на хабре историиснашиваний отношений =D
По поводу быстроты всё зависит от количества создаваемых объектов, тоесть прямоты рук.
А вот с точки зрения доступности и маштабируемости спору нет.
На ФП перепилить/допилить мозг можно быстро, благо уже были на хабре истории
Осмелюсь поделиться личным опытом. Для меня время вхождения в Erlang составило месяц. За это время было прочитано произведение Джо Армстронга и прокурено определенное число публикаций во всемирной паутине. По истечению этого времени я смог писать код промышленного уровня. Процесс перестраивания мозгов на функциональщину доставил кучу удовольствия.
Насколько я знаю это не исключение. Erlang очень легкий для обучения язык. Вот только осознаешь это только когда уже взялся за дело.
Насколько я знаю это не исключение. Erlang очень легкий для обучения язык. Вот только осознаешь это только когда уже взялся за дело.
Пока документация на особо извращенные (то бишь интересные) функции нагоняет страх :) Я принялся изучать erlang года два назад, тогда не особо пошло, но периодически возвращаюсь к нему. Особенно досадно, что мало достойных примеров, так что вам большое спасибо!:)
Приступая к изучению ерланга надо уже знать, что на нём делать, т.е. быть знакомым с проблемной областью. Иначе, изучая его на стандартных примерах с фибоначчами и факториалами, собственно, Erlang/OTP и не изучишь.
Правильные книжки как раз и вводят правильно в предметную область. Насколько я знаю, в этом мире существует ровно 2 (почти одинаковые) книги про непосредственно сам язык (ну и OTP, ибо без него не воспринимается). Армстронга не читал, а сам пользуюсь трудом Франческо Цезарини. Очень грамотно подводит к проблеме, показывает ее и объясняет решение. И примеры не абстрактные факториалы, а какие-то зачатки систем распределения частот, телефонов и подобные. В общем, удивительно, что до сих пор язык в жопе (ну, сравнительной, конечно). Хотя, может оно и к лучшему.
В большинстве случаев он просто не нужен, либо как из пушки по воробьям.
Давайте, все-таки, по существу. Erlang хорош там, где он хорош (хайлоад, concurrency, отказоустойчивость). Зачем его применять там, где он не хорош? Ну давайте вы пожалуетесь, что трактора не нужны, потому что феррари их обгоняет, а огород вы и лопатой вскопаете.
Сам язык вообще довольно простой. Но есть еще платформа OTP со стандартными модулями типа диспетчеров/серверов etc и стандартами создания приложений на Erlang. После того как с синтаксисом и основами разберешься, нужно обязательно OTP поковырять.
Ерланг называют «PHP из мира ФП» как раз за очень низкий порог вхождения. Так что миф о том, что он очень сложен, порождён исключительно предрассудками.
>Это было первой попыткой. 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…
Я не хочу раскрывать все карты сразу :)
Если Вам не терпится, можете взглянуть на часть 3 в оригинале.
Если Вам не терпится, можете взглянуть на часть 3 в оригинале.
уже — прогрыш всё равно остался гигантский
У меня нету большого желания спорить насчет такой небольшой разницы. Но все же.
Из вашей ссылки:
>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) 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…
В Вашем примере автор какраз «забыл» про расходы ядра:
> around 5K per connection but of course not including kernel structures
Почему же в случае с Erlang их нужно считать?
> around 5K per connection but of course not including kernel structures
Почему же в случае с Erlang их нужно считать?
>В Вашем примере автор какраз «забыл» про расходы ядра
точных данных, увы, нет, но есть все основания полагать, что они меньше 10G/2 libevent'а. Можно попробовать повторить эксперимент и оценить накладные расходы
точных данных, увы, нет, но есть все основания полагать, что они меньше 10G/2 libevent'а. Можно попробовать повторить эксперимент и оценить накладные расходы
Боюсь сравнение с groovy в данном случае не корректно. В вашем примере использовался non blocking evented сервер. Подозреваю, что при такой архитектуре все соединения обрабатываются одним покотом и нам тупо нехватит CPU.
Можно ли этот groovy++ сервер запустить на 16ядрах без необходимости дополнительно синхронизировать доступ к общим данным, например, списку открытых сокетов?
В случае с erlang можно запустить хоть на 160 ядрах всех 10 машин кластера.
Можно ли этот groovy++ сервер запустить на 16ядрах без необходимости дополнительно синхронизировать доступ к общим данным, например, списку открытых сокетов?
В случае с erlang можно запустить хоть на 160 ядрах всех 10 машин кластера.
>нам тупо нехватит 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 машин?
Вы не поняли, что Вам хотел сказать товарищ insa. С тем, что приложение на Groovy можно распараллелить никто не спорит.
Но в случае с Erlang это просто и эффективно. Правильный код на Erlang имеет практически линейный рост производительности от числа ядер.
Неблокирующая параллельность это прекрасно.
Но к конкретной задаче CPU не имеет никакого отношения.
Но в случае с Erlang это просто и эффективно. Правильный код на Erlang имеет практически линейный рост производительности от числа ядер.
Неблокирующая параллельность это прекрасно.
Но к конкретной задаче CPU не имеет никакого отношения.
>Но в случае с Erlang это просто и эффективно.
если говорить исключительно о сабжевом примере — groovy не только не уступает, но и даже выигрывает в простоте
>Но к конкретной задаче CPU не имеет никакого отношения.
ну так это и не я начал говорить про CPU, я говорил только о сравнении потребляемой памяти на сабжевом примере-задаче
если говорить исключительно о сабжевом примере — groovy не только не уступает, но и даже выигрывает в простоте
>Но к конкретной задаче CPU не имеет никакого отношения.
ну так это и не я начал говорить про CPU, я говорил только о сравнении потребляемой памяти на сабжевом примере-задаче
> он сам автоматом использует все доступные ядра в пределах одной машины.
Ну, это круто :) Побольше бы таких платформ.
> а сколько будет оверхед от шаринга каких-либо данных на эти 10 машин?
Это скорее зависит от данных, чем от языка программирования. Шарить информацию о 512к открытых соединениях — это вообще не проблема.
Ну, это круто :) Побольше бы таких платформ.
> а сколько будет оверхед от шаринга каких-либо данных на эти 10 машин?
Это скорее зависит от данных, чем от языка программирования. Шарить информацию о 512к открытых соединениях — это вообще не проблема.
Еще по поводу неблокирующего сервера…
Если я в этом Gretty сделаю медленный блокирующий запрос, скажем, к мускулю, то это заблокирует весь сервер? Сможет ли сервер принимать и обрабатывать соединения в это время?
Если я в этом Gretty сделаю медленный блокирующий запрос, скажем, к мускулю, то это заблокирует весь сервер? Сможет ли сервер принимать и обрабатывать соединения в это время?
>Сможет ли сервер принимать и обрабатывать соединения в это время?
конечно. а разве бывают такие сервера, которые не смогут?
конечно. а разве бывают такие сервера, которые не смогут?
Да любой основанный на select/epool/kqueue сервер.
Допустим если я напишу модуль для Nginx который будет медленно запрашивать данные из MySQL через стандартный libmysql для каждого HTTP запроса. Такой сервер с того момента как я выполню mysql_query и до возврата из этой функции не сможет принять/обработать ни одного запроса (ну, с точностью до колличества воркеров нгинкса, которых обычно мало)
Видимо NodeJS, если использовать недоработанный биндинг к MySQL.
Допустим если я напишу модуль для Nginx который будет медленно запрашивать данные из MySQL через стандартный libmysql для каждого HTTP запроса. Такой сервер с того момента как я выполню mysql_query и до возврата из этой функции не сможет принять/обработать ни одного запроса (ну, с точностью до колличества воркеров нгинкса, которых обычно мало)
Видимо NodeJS, если использовать недоработанный биндинг к MySQL.
Если брать в расчёт «стандартный» tomcat, то он тоже ограничен количеством воркеров (а точнее одновременных коннектов), но во-первых их штук 200 по-умолчанию, а во-вторых они друг от друга явно не зависят (хранение сессий в расчёт не принимаем).
Если говорить про коннекты к БД, то они пулятся и друг от друга тоже не зависят.
В вашем случае, я так понимаю, получается что mysql-connector однопоточный что ли?
Если говорить про коннекты к БД, то они пулятся и друг от друга тоже не зависят.
В вашем случае, я так понимаю, получается что mysql-connector однопоточный что ли?
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) в том, что может обрабатывать огромное число соединений.
хм, что-то вы меня совсем запутали…
вот пришёл нам запрос, пусть это будет GET /someurl, как будет отличаться его обработка в случае erlang'а и в случае tomcat'а?
вот пришёл нам запрос, пусть это будет GET /someurl, как будет отличаться его обработка в случае erlang'а и в случае tomcat'а?
Я правда не знаю как работает томкат, не сталкивался. Возьму для примера 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, если да — то пофиг чем обрабатывать).
Java NIO значительно легковеснее врача и может держать сотни тысяч соединений, см, например, blog.urbanairship.com/blog/2010/08/24/c500k-in-action-at-urban-airship/
Что то мне кажется мы входим в рекурсию. Я с Java не знаком, но, как я понял, в статье по вашей ссылке асинхронный сервер… Тут недавно статья появилась habrahabr.ru/blogs/webdev/111357/ там разница более менее понятно описана.
//Минусы не мои
//Минусы не мои
Из питоньих Tornado так же не сможет. Twisted не сможет, но там есть возможность довольно просто использовать пулл соединений с БД
Можно поподробнее почему такие настройки sysctl?
error: «net.ipv4.netfilter.ip_conntrack_max» is an unknown key
((((
вот на это ругнулось net.ipv4.netfilter.ip_conntrack_max
((((
вот на это ругнулось net.ipv4.netfilter.ip_conntrack_max
Реально ли такой финт ушами сделать в Windows? Как я понимаю, для этого требуется возможность изменения сетевых параметров по аналогии с sysctl. Может кто-то делал подобные настройки в Win?
Жаль, что перевод появился тут спустя почти два с половиной года после оригинала. Спасибо, интересная, и по-прежнему актуальная ретроспектива.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Comet–приложение для Mochiweb c нагрузкой в 1 000 000 пользователей. Часть 1/3