>Таким образом получается что однопоточный сервер на poll/select будет лисапедом повторяющим уже готовую реализацию.

Не будет. Жабские потоки тоже жрут ресурсы.

С java NIO дело не имел - мне бизнес-логику нужно сделать, что там внизу не интересно ибо интерес это человеко-дни которые ограничены.

Когда эту логику нужно масштабировать - тогда встает в полный рост этот вопрос.

> Если есть дисковый IO то тут или усложняется код или можно получить глобальные тормоза на IO задержках с диском. А тут уже стает вопрос что дешевле в разработке - очень специфический код на тотальных буферах или напрячь чуть более ядро, а не ноги.

Прошу прощения. а что sendfile(), ну или там VFS AIO уже отменили? Не ну я знаю что у линуха в ядре AIO работает только для локальных FS, для не локальных нужны некоторые телодвижения - но... Чистый демон который получал некий запрос - дальше выполнял кучу http реквестов, и mysql - очень клева ложился в FSM (ну для мускуля приходилось форкаться ибо научить его non blocking io не получалось) - 500-2000 запросов в секунду жило, в одном процессе на каком-то оптероне 2GHz.

>>Может вы мне доку какую дадите чтобы объяснить этот факт.

Такие сервисы существуют 100 лет. Самое распространенное применение в MUDах. Абсолютно однопроцесные сервера обслуживащие кучи параллельных персистентных соединений.

все что выше можно описать одной строчкой - рисуем машину состояний для сокета.

2VoDA: Откройте в википедии что такое FSM (Finite State Machine), и насрисуйте ее для обмена через сокет, и через AIO в линухе (хз во что оно там у java мапится).

кроме MUD есть еще более известный вариант - веб сервера - nginx тот же.

О. нашелся документ имени товарища Нечаева - FAQ от Ru.Unix.prog - http://linuxtell.com/faq/

must have to read.

PS. MUD не очень интересный пример - там ооочень много вялотекуших соединений.

> Так тут ситуация такая что в Java используются треды VM, треды ОС применяются только в RealTIme Java и только для RealTime тредов. Таким образом получается что однопоточный сервер на poll/select будет лисапедом повторяющим уже готовую реализацию.

Не зачет по теории строения JVM. JVM по сути реализует модель M:N - когда все количество тредов внутри JVM мапится в ограниченое количество ядерных тредов. в случае RT java - там 1:1 насколько помню.

А выигрыш select, poll простой - в случае тредов - ты не можешь представить в какой момент твой тред остановят и переключат на другой (очень может быть что он будет с захвачеными ресурсами) и может так случаться что другой тред будет ждать освобождения shared resource - в случае FSM у тебя принципиально нету блокировок и нет таких проблем, когда бы выполнение не было прервано - никто другой не будет ждать ресурсов этого процесса.

PS. не ужели в институтах/универах перестали читать лекции по этой теме? проблемы доступа к shared resource и голодание уж должны были разбирать.. как и построение FSM.

энергетиков перепил? прочитай ещё раз, что написано

1-2-3-5 понятны и адекватны. Когда было нечем заняться делал самопальные обработчики сразу поверх сокета.

4. обработка запроса запишет в исходящий буфер результатю

Этот пункт является самым затратным по времени. Чтобы не простаивали обработка входящих (т.е. пришли еще запросы пока мы сидим в точке 4) придется выкидывать его обработку в отдельные треды?

> Не будет. Жабские потоки тоже жрут ресурсы.

Конечно. Только они едят намного меньше чем треды ОС. По сути на 100 МЬ потоков могут быть подняты только 5 тредов в ОС. Для минимизации простоя ОС-ных тредов.

Когда эту логику нужно масштабировать - тогда встает в полный рост этот вопрос.

Пока самым эффективным средством масштабирования была доработка архитектуры приложения. На более грамотной архитектуре крутилось все заметно быстрее.

Плюс параллельная обработка на разных нодах. Купить еще одну ноду стоит примерно как ЗП одного разработчика за месяц. Чаще дешевле закупить еще серверов, чем глубоко оптимизировать. Наверное как только сложность системы вырастет вперед развития hardware настолько, что изучение NIO и изменение архитектуры будет дешевле покупки сервера, так сразу начнем учить и тюнить Tomcat/JBoss под NIO.

PS Tomcat поддерживает NIO. Вопрос насколько грамотно и можно ли применить out-of-box остается открытым.

> JVM по сути реализует модель M:N - когда все количество тредов внутри JVM мапится в ограниченое количество ядерных тредов. в случае RT java - там 1:1 насколько помню.

Правильно. JVM N:M, RT JVM - 1:1 для RT тредов и N:M для обычных.

А выигрыш select, poll простой - в случае тредов - ты не можешь представить в какой момент твой тред остановят и переключат на другой (очень может быть что он будет с захвачеными ресурсами) и может так случаться что другой тред будет ждать освобождения shared resource - в случае FSM у тебя принципиально нету блокировок и нет таких проблем, когда бы выполнение не было прервано - никто другой не будет ждать ресурсов этого процесса.

ОК. на чем выигрыш понятно - работает в треде пока не завершим работу. Без перерыва.

Специально пишется чтобы shared resource было поменьше.

PS. не ужели в институтах/универах перестали читать лекции по этой теме? проблемы доступа к shared resource и голодание уж должны были разбирать.. как и построение FSM.

FSM у нас вообще не пробегали, зато было управление электро-двигателями. бИда которая не актуальна уже лет Н-цать ИМО.

> 4. обработка запроса запишет в исходящий буфер результатю

Этот пункт является самым затратным по времени. Чтобы не простаивали обработка входящих (т.е. пришли еще запросы пока мы сидим в точке 4) придется выкидывать его обработку в отдельные треды?

Network RDMA или Zero-copy sockets уже отменили? А кроме того самое затратное не чтение - а разборка того что прочитали.

> ОК. на чем выигрыш понятно - работает в треде пока не завершим работу. Без перерыва.

Ты действительно не понимаешь что взятие семафора, мьютекса может инициировать context switch? а задачи которые могут быть обработаны без shared resource - напрашивается реализовать как отдельные процессы (а не треды). Так же как то что тред не может работать бесконечно время - треды вытесняются, и могут быть прерваны. Один фик context switch даже на уровне jvm это не бесплатно.

FSM у нас вообще не пробегали, зато было управление электро-двигателями. бИда которая не актуальна уже лет Н-цать ИМО.

Теория конечных автоматов это вобще азы дискретной математики. Крайне самонадеянно лесть в программирование и оптимизации не изучив дискретку.

ps. http://pllab.cs.nthu.edu.tw/cs5403/Papers/NetworkProcessor/cthpc2004.pdf http://www.computer.org/portal/web/csdl/doi/10.1109/NAS.2008.55 и какой нить ring buffer. или еще что.. что бы избежать

>> Этот пункт является самым затратным по времени. Чтобы не простаивали обработка входящих (т.е. пришли еще запросы пока мы сидим в точке 4) придется выкидывать его обработку в отдельные треды?

Network RDMA или Zero-copy sockets уже отменили? А кроме того самое затратное не чтение - а разборка того что прочитали.

Самое затратное это выполнить саму бизнес-логику по прочитанному, поднять данные из БД, кэшей и т.п. Разборка прочитанного сообщения бесконечно меньше по времени и коду.

> Ты действительно не понимаешь что взятие семафора, мьютекса может инициировать context switch? а задачи которые могут быть обработаны без shared resource - напрашивается реализовать как отдельные процессы (а не треды). Так же как то что тред не может работать бесконечно время - треды вытесняются, и могут быть прерваны. Один фик context switch даже на уровне jvm это не бесплатно.

семафора ОС или о каком семафоре говорим? Context switch на уровне JVM не обязательно приведет к context switch в OS. Даже вероятнее что не приведет. Хотя тут уже нужно смотреть как JVM-семафоры сделаны.

Теория конечных автоматов это вобще азы дискретной математики. Крайне самонадеянно лесть в программирование и оптимизации не изучив дискретку.

программирование вообще не требует высшего образования - код писать довольно просто. Оптимальной должна быть архитектура. А оптимизацией нужно заниматься в двух случаях - либо система уперлась в верхние ограничения железа и дальше вытягивать железом экономически не эффективно, либо команда уже делала подобный проект и заранее известны подводные камни конкретной реализации.

PS программиста без вышки не возьму, но по причинам отличным от знаний которые даются в Универе. PPS приходил как то профессор на собеседование. такое огромное количество умных слов... возникает призрак того, что человек много знает. именно призрак.

>> как может однопоточный сервер работать быстрее многопоточного на большом количестве обращений?

Если у тебя не гарантировано короткий ответ то poll/select будет грузить только то сетевое IO которое к этому готово. В общем нагрузка попроще чем в thread-per-connection.

А теперь вернемся к тому что у тебя не реальный параллелизм, а псевдо. На чем собственно процессор у тебя простаивает? На блокированном IO, и псевдо решает эту проблему. На чем он теряет? На переключениях контекста

Ок. хорошо я почти верю, что однопроцессные серверные приложения быстрее многопроцессных на многоядерных-многопроцессорных серверах.

Только почему тот же nginx на который мне указали как пример (http://www.linux.org.ru/news/opensource/5634827/page5?lastmod=1291463256322#c...) сделан не однопроцессным, а многопроцессным? Цитата с саайта разработчиков: «один главный процесс и несколько рабочих» (http://sysoev.ru/nginx/)

И почему тот же Apache HTTP имеет множество MPM (Мультипроцессорных моделей)? Ведь уже практически доказано, что однопроцессная обработка быстрее. И, вероятнее, проще в разработке?

> 2VoDA: Откройте в википедии что такое FSM (Finite State Machine), и насрисуйте ее для обмена через сокет, и через AIO в линухе (хз во что оно там у java мапится).

кроме MUD есть еще более известный вариант - веб сервера - nginx тот же.

nginx - многопроцессное приложение. Цитата: «один главный процесс и несколько рабочих». Я же просил объяснить мне как однопроцессное приложение может быть быстрее многопроцессного. Так что в данном случае это пример в поддержку моего понимания, что многопроцессные приложения обрабатывают множественные запросы быстрее однопроцессных

>Прошу прощения. а что sendfile(), ну или там VFS AIO уже отменили?

А сервисы ои не ограничиваются пересылкой файла и если чтение значительных данных для обработки однопроцесное чтение сделает респонсивнесс сервера не особенно, или придется заниматься дроблением - что уже нетривиальный код.

Я не говорю что это нельзя сделать - я говорю о том что тут встает вопрос а стоит ли заморачиваться. При чем вариант ответа стоит - наличествует - просто может стоить не всегда.

Если мой склероз не изменяет - там была схема когда accept socket разделялся между стопкой процессов - каждый из которых релизовывал свой конечный автомат. Ну и «главный процесс» выступал просто диспечером.

>все что выше можно описать одной строчкой - рисуем машину состояний для сокета.

У меня - children edition.

>Чтобы не простаивали обработка входящих (т.е. пришли еще запросы пока мы сидим в точке 4) придется выкидывать его обработку в отдельные треды?

Нет - придется посмотреть где оно там затратится и разбить на несколько фаз.

>Плюс параллельная обработка на разных нодах. Купить еще одну ноду стоит примерно как ЗП одного разработчика за месяц.

Зависит от того насколько линейно масштабирование. Взять те же nosql eventually consistent базы. С каждым нодом время достижения этой консистентности все увеличивается, и внутренний обмен все больше растет, что требует больших ресурсов, дальнейшее масштабирование -> черная дыра. Потом встает вопрос файловерности каждой ноды и вообще все становиться не так просто.

так сразу начнем учить и тюнить Tomcat/JBoss под NIO.

Их давно тюнят. http://tomcat.apache.org/tomcat-6.0-doc/aio.html

Просто решение несколько эээ «абстрактное» и весь нио там в общем ограничен или коментом или просто сокетным чтением и записью ограничен а как только считал - все в треды.

>один главный процесс и несколько рабочих

Эти несколько рабочих и разкладываются на SMP + наверняка они качественно отличаются и главный процесс длиспатчит на них работу в зависимости от того что это за работа. Так можно делать модульность.

И почему тот же Apache HTTP имеет множество MPM (Мультипроцессорных моделей)?

Есть такие звери как права. Есть такие звери как релаябилити всего того говна которое подключается в виде модулей.

И, вероятнее, проще в разработке?

Нет.

> НЕПРЕРЫВНОЙ интеграции

Роза пахнет розой. Хоть розой назови её, хоть нет (с)

В Питере?))

Да, Питер. Актуально?

Если коротко, то Hudson весьма странный.. Особенно когда время билда > 3-4 часов.

Для трехчасового билда непрерывная интеграция не имеет смысла. Почитай Фаулера - http://www.martinfowler.com/articles/continuousIntegration.html

Вы конечно перегнули процентов эдак на 50, но все таки аплодирую стоя (за 5 лет в NC чего только не повидал)

не тебе решать

каждому - своё: одним - всякие вордпресы, mariadb, mysql, другим - мультики, на горшок и баиньки

Корпорасты создают тысячы рабочих мест, инфраструктуры, инновации и вообще какое-то движение вперед. А опенсорс, кроме безликой толпы, постоянно ноющей «Мелочишка... Мелочь есть? Подай монетку...» ничем особо и не выделяется.

Толсто же.

Ты бы еще позже вылез...