Здравствуйте, vdimas, Вы писали:
N>>>>Если бы это было серьёзной проблемой, давно бы в винде встроили SCTP из коробки. V>>>Причем тут SCTP? N>>Message-oriented с гарантией доставки, всё, как ты просил. V>А разве по нему можно пулять произвольные сообщения?
Да, месье Журден.
V>Ну и дело-то не в винде, ес-но. Весь интернет построен на юникс-совеместимых системах. Винда больше на клиенте.
Во всех юниксах он уже давно работает без проблем, торможение только за виндой.
V>Ну и проблему установления и разрыва TCP-соединения тоже ведь не я придумал. Т.е. вот этот ненужный пинг-понг, он же не только при установлении TCP-соединения происходит?
Почему это он ненужный?
V> Помнишь же ту оптимизацию, когда рекомендуется для сокращения пинг-понгов рвать соединение не клиентом, а сервером? )) V>Но в реальности соединение чаще рвет клиент-браузер, гоняя по сети уйму ненужных пакетов.
Ну так в http2 это их мультиплексирование (откровенно странное) уменьшает эту проблему.
Здравствуйте, BulatZiganshin, Вы писали:
I>>А как по твоему два процесса смогут работать с одним файлом, что бы гарантировать определенную последовательность записей ? I>>
BZ>а ровно так же, как и один процесс. просто не использовать yield в середине логичексой операции
Вот странно, у меня в книге про эту винду есть мутексы. Может книга про NT 3.51, тогда, конечно, всё меняется
Здравствуйте, Ikemefula, Вы писали:
НС>>Что то я не видел в предыдущем твоем вещании упоминания того, что это касается проблем конкретного инструментария. I>Намекаешь, что мне в каждом сообщении напоминать, что я говорю в основном про нод ?
Намекаю на то, что топик вообще то про Erlang и личные половые трудности твоего нода тут не совсем в тему. Более того, в том сообщении на которое ты отвечал был явно упомянут Erlang+OTP, так что ты точно был в курсе что обсуждают именно его.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Что то я не видел в предыдущем твоем вещании упоминания того, что это касается проблем конкретного инструментария. I>>Намекаешь, что мне в каждом сообщении напоминать, что я говорю в основном про нод ?
НС>Намекаю на то, что топик вообще то про Erlang и личные половые трудности твоего нода тут не совсем в тему. Более того, в том сообщении на которое ты отвечал был явно упомянут Erlang+OTP, так что ты точно был в курсе что обсуждают именно его.
Здравствуйте, BulatZiganshin, Вы писали:
I>>Вот странно, у меня в книге про эту винду есть мутексы. Может книга про NT 3.51, тогда, конечно, всё меняется
BZ>а что там ещё есть? createfile, createthread, locallock?
Книги под рукой нет, я заглядывал туда примерно зимой в последний раз.
Здравствуйте, Mamut, Вы писали:
M>Главное в споре что? Правильно. Наугад давать разнообразные все более идиотские ограничения оппоненту, полностью игнорируя его, оппонента, доводы.
Не мешало бы, чтобы главный популяризатор Erlang-а в этой теме читал ветки обсуждения.
M>С какого перепугу в споре вдруг появился Raspberry Pi? А потому что некому so5team так ВНЕЗАПНО захотелось. Ведь каких-либо внятных аргументов у него нет. От слова вообще.
, но совершенно ничего не сказал про аппаратную базу, то лично я бы видел смысл в разработке веб-сервера для задачи Sinclair-а на C++ только для маломощных и специализированных устройств. Примером которого и является Paspberry Pi.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, netch80, Вы писали:
N>>Во всех юниксах он уже давно работает без проблем, торможение только за виндой.
НС>А смысл ждать, чтобы он непременно в ОС был? Сторонние реализации, сам говоришь, имеются. И даже мосты есть.
Для мира "внутреннего" и "консультативного" софта действительно пофиг. А вот чтобы понять, что мешает "коробочному", надо быть экспертом в нынешней винде. Я ни разу не такой эксперт, так что вопрос не ко мне.
Здравствуйте, Sinclair, Вы писали:
S>чтобы ваше решение не отжирало 7GB RAM только под initial stack commit.
Sinclair, 7Gb RAM появились как демонстрация вашего незнания того, на что способны современные ОС и какой ценой это достигается. А вовсе не пример того, как нужно разрабатывать приложения.
S>Но вы, похоже, просто вообще не понимаете, как устроен современный высокопроизводительный сетевой сервер, и в чём тут специфика задачи.
До сих пор речь шла о Web-серверах. В Web-серверах, действительно понимаю немного. В сборке Web-приложений для раздачи разных типов контента вообще не понимаю, т.к. никогда этим не занимался.
S>>Кто вам сказал, что данные приходят по 200 байт раз в секунду? Или у вас опять информация из 2009-го года? S>Это типичная ситуация для тех задач, под которые проектировался Эрланг.
Под которые проектировался Erlang, может быть. Кто вам сказал, что у нас данные ходили по 200 байт раз в секунду?
S>>Ну так покажите тот. А то вы кроме yaws ничего и не знаете. S>Я тот показал. Но вы полагаете, что nginx за пять лет ускорился в разы, а yaws на это неспособен. Что ж, ваше право заблуждаться у вас никто не отнимет.
Да мне-то все равно. Вы себе позволяете в 2015-м году козырять результатами одного бенчмарка от 2009-го года.
Занятно, что за Erlang вписываются люди, которые на Erlang ничего не писали, в качестве доказательства применимости Erlang-а для высоких нагрузок приводят какие-то древние yaws, MochaWeb и не слышавшие ни про Cowboy, ни про N2O. И уж тем более, ни про RabbitMQ, ни про CouchDB. Уровень Ыкпертизы прям зашкаливает.
Здравствуйте, Mamut, Вы писали:
S>>Собственно, хочется выяснить, за счет чего этот пункт удовлетворяется в Erlang-е.
M>За счет рантайма вестимо.
Это весь уровень ваших знаний?
Такой ответ не катит. Давайте подробности. Например, есть ли какие-то гарантии по работе receive? Есть ли гарантии по времени активации процессов? Сколько приоритетов доступны процессам в Erlang VM? Есть ли гарантии по временам работы GC?
S>>Ну и, если он таки удовлетворяется, почему Mamut считает, что этот пункт в других платформах в зачаточном состоянии.
M>Потому что в других платформах рантайм этого не гарантирует, вестимо.
Здравствуйте, so5team, Вы писали:
F>>с куда как большими затратами времени, сил и денег. S>Лично у вас есть опыт разработки приложений с помощью Akka (не суть важно, на Scala или Java)?
Здравствуйте, neFormal, Вы писали:
F>>>с куда как большими затратами времени, сил и денег. S>>Лично у вас есть опыт разработки приложений с помощью Akka (не суть важно, на Scala или Java)?
F>ага.
Отлично. У вас, значит, такой опыт. У других людей обратных -- они предпочитают Akka Erlang-у.
Здравствуйте, so5team, Вы писали: S>Sinclair, 7Gb RAM появились как демонстрация вашего незнания того, на что способны современные ОС и какой ценой это достигается. А вовсе не пример того, как нужно разрабатывать приложения.
Я уже понял, что вам интереснее обсуждать мои знания, чем решать задачу. Можете в эту сторону аргументацию не продолжать — это технический форум, а не забег в пенисометрии.
S>До сих пор речь шла о Web-серверах. В Web-серверах, действительно понимаю немного. В сборке Web-приложений для раздачи разных типов контента вообще не понимаю, т.к. никогда этим не занимался.
В web-серверах никакой особенной специфики по сравнению, скажем, с ftp-серверами, smtp-серверами, и imap-серверами нету.
Везде одно и то же: общение с каждым клиентом — долгая коммуникационная сессия, во время которой сервер большую часть времени спит. Диаграмма состояний, описанная в RFC, прямо-таки просит реализовать это в виде "1 клиент = 1 поток". Что в мире unix, как правило, превращается в "1 клиент = 1 процесс". А потом вдруг и выясняется, что qmail на линуксе держит нагрузку хуже, чем exchange на винде, несмотря на более удачную реализацию сетевого стека. И решения, написанные энтузиастами в 90х, вымирают, потому что им на смену приходят более вменяемые архитектуры.
Да-да, те самые, которые внутри себя тащат половину Эрланга.
S>Под которые проектировался Erlang, может быть. Кто вам сказал, что у нас данные ходили по 200 байт раз в секунду?
Да я уже понял, что вы говорите не про роутинг пакетов в реальном времени, а про ленивый парсинг CDR. На всякий случай подчеркну: для конкретно этой задачи Erlang подойдёт заведомо хуже, чем ruby. Хорошо подойдет что-то другое, причём совершенно не факт, что именно С++. S>Вы себе позволяете в 2015-м году козырять результатами одного бенчмарка от 2009-го года.
Ну, по крайней мере это бенчмарки Эрланга. Вы в опровержение этих бенчмарков мне приводите бенчмарки парсинга текстов на Руби. Ну, да, у них преимущество: они свежие. Я ёще могу порекомендовать вам бенчмарки на http://tpc.org — они, во-первых, ещё более свежие, а во-вторых — там ни в одном месте нет Эрланга.
Насколько я понял вашу логику, это делает их идеальными для использования в сравнениях между Эрлангом и С++.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Sinclair, 7Gb RAM появились как демонстрация вашего незнания того, на что способны современные ОС и какой ценой это достигается. А вовсе не пример того, как нужно разрабатывать приложения. S>Я уже понял, что вам интереснее обсуждать мои знания, чем решать задачу.
Так продемонстрируйте знания. Вы же спрашивали, какая ОС позволит запустить 100K нитей. Уровень экспертизы уже можно оценить.
S>>До сих пор речь шла о Web-серверах. В Web-серверах, действительно понимаю немного. В сборке Web-приложений для раздачи разных типов контента вообще не понимаю, т.к. никогда этим не занимался. S>В web-серверах никакой особенной специфики по сравнению, скажем, с ftp-серверами, smtp-серверами, и imap-серверами нету.
Не нужно мне рассказывать особенности демультиплексинга I/O, такие вещи доводилось проходить самостоятельно.
Только одно дело работать с низким уровнем, вроде select/epoll/kqueue/IOCP и представлять себе особенности парсинга HTTP или SMTP/POP3. Другое дело -- строить Web-приложения у которого "80% запросов — статика (т.е. отдаются с диска), 20% — динамика".
S>Везде одно и то же: общение с каждым клиентом — долгая коммуникационная сессия, во время которой сервер большую часть времени спит.
Скажем, не спит, а не выполняет никакой работы, связанной с конкретной сессией. При этом сервер на 100% может быть загружен другими активностями.
S>Диаграмма состояний, описанная в RFC, прямо-таки просит реализовать это в виде "1 клиент = 1 поток".
"прямо-таки просит" не означает, что так нужно и так будет наиболее эффективно.
S> Что в мире unix, как правило, превращается в "1 клиент = 1 процесс".
Смотрим на тот же nginx и видим совсем не такую картину. Смотрим на lwan, один из самых шустрых HTTP-серверов на данный момент, и опять ничего подобного не видим.
Более того, не нужно забывать, что Web начинался с CGI, а самый простой и надежный способ реализации CGI как раз был в использовании формулы "process per client". Только это было более чем 20 лет назад. Когда в некоторых Unix-ах минимальной единицей диспетчеризации еще был процесс, а не нить (thread).
S>>Под которые проектировался Erlang, может быть. Кто вам сказал, что у нас данные ходили по 200 байт раз в секунду? S>Да я уже понял, что вы говорите не про роутинг пакетов в реальном времени, а про ленивый парсинг CDR.
Вы, не смотря на высокое мнение о своих умственных способностях, ничего не поняли.
Во-первых, обработка PDU -- это далеко не только парсинг. Да и парсинг, если он не укладывается в возможности регулярных выражений или erlang-овских binaries, реализованных, как правило, хардкорным C-шным кодом, в динамике не быстр. Кроме парсинга в обработке PDU есть еще куча действий, в которых динамика проигрывает статике. Если интересно, погулите материалы Юрия Жлобы про механизмы логирования в Erlang-е, тормоза и способы борьбы с ними.
Во-вторых, когда по одному каналу 200 байт начинает ходить не раз в секунду, а двести раз в секунду, и каждый пакет нужно подтверждать с минимальной задержкой, картинка очень сильно отличается от "200 байт раз в секунду". Тем более, что канал далеко не один.
В-третьих, вы либо докажите, что знаете, что такой реальное время, либо прекратите этот термин использовать. А то сейчас любой форумный трепач с умным видом говорит про real-time processing даже в ситуациях, когда речь идет об online processing-е.
S>Ну, по крайней мере это бенчмарки Эрланга. Вы в опровержение этих бенчмарков мне приводите бенчмарки парсинга текстов на Руби.
Вы что-то путаете. Опыт из Ruby был приведен в качестве примера, показывающего почему мы не использовали динамику при работе с такими вещами, как GSM/SMPP/UCP.
Я вас просил привести хоть какие-то свежие сравнения Erlang-овых серверов с тем же nginx. Поскольку сам я найти их не могу, самое последнее сравнение датируется 2011-м, что тоже довольно давно.
При этом сами по себе бенчмарки для Web-фреймворков и серверов находятся влет, в том числе и самые свежие. Только вот что интересно -- там либо нет Erlang-а, либо же Erlang сравнивается с какой-нибудь другой динамикой, вроде JS или Clojure. Что еще интересно, в последние годы в материалах, касающихся использования Erlang-а в Web-е, в основном упоминаются сервера Cowboy и N2O, а не yaws. Что еще более красноречиво говорит об уровне вашей экспертизы, застрявшей, в лучшем случае, где-то на уровне 2009-го года.
Здравствуйте, so5team, Вы писали: S>Так продемонстрируйте знания.
Мне интереснее обсуждать задачу и решения.
S>Не нужно мне рассказывать особенности демультиплексинга I/O, такие вещи доводилось проходить самостоятельно.
Ну вот видите, а делаете вид, что впервые слышите.
S>Скажем, не спит, а не выполняет никакой работы, связанной с конкретной сессией.
Совершенно верно. S>При этом сервер на 100% может быть загружен другими активностями.
Может быть. А может не быть.
S>"прямо-таки просит" не означает, что так нужно и так будет наиболее эффективно.
Так будет наименее неэффективно. Несмотря на то, что "современные ОС позволяют запустить 100к потоков".
S>Смотрим на тот же nginx и видим совсем не такую картину.
Совершенно верно. S>Более того, не нужно забывать, что Web начинался с CGI, а самый простой и надежный способ реализации CGI как раз был в использовании формулы "process per client".
Ну вот CGI и есть "process per client", и то, что веб начинался с него — и есть иллюстрация к моему тезису о том, что нормальную архитектуру на традиционных платформах делать тяжело. Вместо неё делают "что получится", а потом мы удивляемся, почему Апач, несмотря на почтенный возраст, огромное коммьюнити, и доминирование на рынке, до сих пор не может решить проблемы с быстродействием.
А единственный известный человечеству пример веб-сервера, написанного на С++, принадлежит компании, у которой на момент его разработки был крупнейший в мире R&D бюджет.
Если принять вашу точку странную идею о том, что по популярности инструмента можно судить о его техническом совершенстве, то окажется, что самый удобный для проектирования высоконагруженных серверов язык — это чистый С, а С++ курит в сторонке.
S>Во-вторых, когда по одному каналу 200 байт начинает ходить не раз в секунду, а двести раз в секунду, и каждый пакет нужно подтверждать с минимальной задержкой, картинка очень сильно отличается от "200 байт раз в секунду". Тем более, что канал далеко не один.
Я правильно понимаю, что AXD-301 не работает? Ведь там же динамика, а 200 байт там ходят не раз в секунду?
S>В-третьих, вы либо докажите, что знаете, что такой реальное время, либо прекратите этот термин использовать.
Reacting to events at the same rate and sometimes at the same time as they unfold.
Скажем, доставка электронного письма — это не оно, потому что никто не обещает никаких SLA.
Доставка instant message — то же самое: opportunistic response. А вот, скажем, обработка голосового трафика — реальное время. Потому что клиент не будет ждать прихода пакета неопределённое время. Несмотря на то, что современный голос работает поверх систем, которые никаким требованиям даже firm real time не соответствуют, а реальные задержки составляют единицы секунд, это всё ещё real-time задача.
S>А то сейчас любой форумный трепач с умным видом говорит про real-time processing даже в ситуациях, когда речь идет об online processing-е.
Тот, на кого вы ссылаетесь, говорит о soft real-time computing. А что вы называете online processing — я не в курсе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Мне интереснее обсуждать задачу и решения.
Решение в настоящий момент будет строится из уже готовых компонентов, и далеко не факт, что программистом, а не системным администратором.
S>>"прямо-таки просит" не означает, что так нужно и так будет наиболее эффективно. S>Так будет наименее неэффективно. Несмотря на то, что "современные ОС позволяют запустить 100к потоков".
О том, что не нужно запускать 100k потоков было сказано давным давно
(смотреть абзац, где упоминается SEDA).
Причем, если обработку сессий представлять в виде короутин, то получается очень похоже на Erlang. А если не в виде короутин, а в виде конечных автоматов, то совсем не похоже. При этом подходы на основе КА успешно используются уже фиг знает сколько времени.
S>Ну вот CGI и есть "process per client", и то, что веб начинался с него — и есть иллюстрация к моему тезису о том, что нормальную архитектуру на традиционных платформах делать тяжело.
Взгляды на то, как делать нормальную архитектуру уже давным-давно эволюционировали даже у мейнстрим-разработчиков.
S>Вместо неё делают "что получится", а потом мы удивляемся, почему Апач, несмотря на почтенный возраст, огромное коммьюнити, и доминирование на рынке, до сих пор не может решить проблемы с быстродействием.
Ситуация с Apache такова как раз не "несмотря", а именно потому что почтенный возраст и огромное коммьюнити.
S>Если принять вашу точку странную идею о том, что по популярности инструмента можно судить о его техническом совершенстве, то окажется, что самый удобный для проектирования высоконагруженных серверов язык — это чистый С, а С++ курит в сторонке.
На данный момент получается именно так (только с поправкой на "реализацию", а не "проектирования", ни С, ни C++ не являются языками для проектирования).
Тому есть множество причин. Если брать только технические, то до сих пор проблем с кроссплатформенной разработкой на C меньше, чем с C++.
S>Я правильно понимаю, что AXD-301 не работает? Ведь там же динамика, а 200 байт там ходят не раз в секунду?
Вы опять куда-то в сторону. Я вам указываю на то, что ситуация, когда на динамике нужно обрабатывать 200 байт из канала раз в секунду, принципиально отличается от ситуации, когда нужно обрабатывать по 200 байт 200 раз в секунду. А вы тычите в AXD-301, исходников которого не видели ни я, ни, полагаю, вы.
Что и как происходило в AXD-301 -- это открытый вопрос. Даже в самой первой его реализации, согласно данным одного из разработчиков кроме 1M строк кода на Erlang-е, было 400K строк на C++ + еще около 600k строк на С (500k строк в неких device processor-ах и 100k строк в сторонних компонентах, управлявшихся из Erlang-овых процессов). Суммарно 1M строк на C и C++ заставляет задуматься о том, что с динамикой было не все так просто в AXD-301.
S>>А то сейчас любой форумный трепач с умным видом говорит про real-time processing даже в ситуациях, когда речь идет об online processing-е. S>Тот, на кого вы ссылаетесь, говорит о soft real-time computing. А что вы называете online processing — я не в курсе.
Real-time -- это гарантия реакции на событие в заданных временных пределах. Hard real-time -- это катастрофический результат в случае невыполнения временных условий. Soft real-time -- это не катастрофические последствия при небольшом количестве случаев невыполнения временных условий. Online -- это минимальная задержка реакции на события, но без каких-либо реал-таймовых гарантий. Собственно, когда Soft real-time требования снижаются до того, что могут быть выброшены большинство просроченных результатов обработки, речь уже идет про online processing, а не real-time.
Я знаю про особенности работы и гарантии, которые предоставляет AXD-301 недостаточно много, чтобы сделать вывод о том, идет ли там речь об real-time или об online. Поскольку снятие звука с микрофона, компрессия и подготовка к передаче набора PDU-шек, когда все это делается внутри трубки -- это чистой воды real-time. Тогда как передача PDU через кучу оборудования на трубку абонента... Ну, может быть это и soft-real-time, хотя чем такой real-time отличается от online-processing-а понять сложно.
