Каморка

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

Это так же как реляционные системы баз данных - не программистское это дело, заниматься администрированием и оптимизацией структуры БД. На одном и том же приложении она может меняться очень сильно, оставаясь прозрачной для приложения.

Zy писал(а):Детали всегда имеют значение, но ими должен заниматься специально обученный человек, а когда один программист должен заботится обо всех деталях работы, то скорее всего он будет делать это плохо, т.к. нельзя одинаково хорошо знать такие различные аспекты работы.

конечно можно. это разговор из серии "зачем оптимизировать код, когда
можно добавить GHz" ... то есть ни о чем. устраивают вас пулы тредов в
рамках джавы - ради бога. оригинальный вопрос никакого отношения к
джаве не имел и вне джавы threading в high-performance серверах
используется крайне ограничено. in my experience естественно.

"зачем оптимизировать код, когда
можно добавить GHz"

Добавить мегагерцы в 99% ситуаций существенно дешевле, чем оптимизировать код, но это не тот случай.

В данной ситуации проектирование идет не с того конца: надо было бы сначала выбрать решение, а потом под него архитектуру, а не наоборот.

Zy писал(а): Добавить мегагерцы в 99% ситуаций существенно дешевле, чем оптимизировать код, но это не тот случай.

Нет, не дешевле во многих случаях. Более того, в данном случае удаение и даже утроение мегагерцы ни как не скажется на производительности сервера с архитектурой "one-thread-per-client". Здесь проблема в ресурсах. Это работает только при небольшом числе клиентов.

Zy писал(а): В данной ситуации проектирование идет не с того конца: надо было бы сначала выбрать решение, а потом под него архитектуру, а не наоборот.

Виноват, ... я не пояснил, что это был не реальный проект, а интервью по телефону с одними из гуру из очень навороченной фирмы в Миссиссаге (не прошёл ). Поэтому вопрос о " выбрать решение" не стоял для конкретной задачи.
Кроме того, есть у MS есть общие технологии в разработке серверных архитектур ( не одна, конечно), например, IOCPs. Это может быть использовано, как с сокетами, так и в равной степени с пайпами и файлами. Поэтому вполне можно говорить об архитектурах в целом.

Нет, не дешевле во многих случаях.

Да, в 1% случаев. Но так как програм в мире пишется очень много, то 1% в штуках достаточно много.

Более того, в данном случае удаение и даже утроение мегагерцы ни как не скажется на производительности сервера с архитектурой "one-thread-per-client".

Т.е. на компьютере intel 286 и intel p4 это будет работать с одинаковой скоростью?

Zy писал(а):

Нет, не дешевле во многих случаях.

Да, в 1% случаев. Но так как програм в мире пишется очень много, то 1% в штуках достаточно много.

Хотелось бы с тобой согласиться. Потому, что в 90% компаний, где я проходил интервью требуется умение писать именно оптимизированный код.

Zy писал(а):

Более того, в данном случае удаение и даже утроение мегагерцы ни как не скажется на производительности сервера с архитектурой "one-thread-per-client".

Т.е. на компьютере intel 286 и intel p4 это будет работать с одинаковой скоростью?

Ты ведь понял меня. Не так ли? Вопрос в том, что нужно стремиться к идеалу используя минимальное число объектов многозадачности:

MS says.... CreateIOCompletionPort. ... So what should n be? In other words, what is a good number of threads to dispatch? Well, if your computations are CPU-bound, you should probably dispatch no more threads than there are processors in the machine you run the server application on. Passing 0 to the number of threads parameter will default to the number of processors, or you can use the GetSystemInfo system service to obtain the number. For I/O-bound operation, you can probably afford a higher degree of concurrency.

Вопрос в том, что нужно стремиться к идеалу используя минимальное число объектов многозадачности

Зачем?

мне вот что неясТТно. Что делать если время ответа недетерминировано. Представим, что система ищет собственный вектора для матриц, размер которых неопределен. Ежели ето 3 на 3 - да ради бога можно на селекте (на люьом диспатч механизме) а ежеди 5 на 5? ОК - в данной задаче можно определить по размерности матрицы время счета, хотя вру - юзер задал мартицу 10 на 10, но она блин диагональная - вектора мы ему сразу отдадим...

Эта одна проблема

Что касается 1000 клиентов - ну зачем делать 1000 тредов? Достаточно сделать 10-к, и уменьшать или увеличивать в зависимости он надобностей:)
Ето я не на Саню наезжаю, а на екстримисткий взгляд - треды сакс, селект форева

Zy писал(а):

Вопрос в том, что нужно стремиться к идеалу используя минимальное число объектов многозадачности

Зачем?

Нельзя клиента держать в отдельном треде, пока тред блокирован блокирующей I/O операцией, например, ждём данных от клиента (а оператор ушёл покурить), или пытаемся в этом треде выполнить сложную обработку данных, запрошенных этим клиентом и только потом отправить данные клиенту в этом же треде.
Чего держать тред, если для этого клиента в данный момент нет данных для обработки?

При большом количестве клиентов не надо открывать тред на клиента, тред(ы) надо открывать на события.

В реальной жизни, кстати, так и происходит: например, в большом магазине типа IKEA есть консультанты, которые помогают выбрать товар (треды consulting) и меньшее по сравнению с консультантами количество кассиров (треды payment). Если магазин маленький, то консультант может быть в то же время и кассиром.

Количество открытых тредов определяется нагрузкой на сервер и определяется динамически(сервера приложений в j2ee).

ждём данных от клиента

Я не знаю, как это происходить у MS, но в java/unix есть каналы, ничего ждать не надо.

Zy писал(а):При большом количестве клиентов не надо открывать тред на клиента, тред(ы) надо открывать на события.

Так а я о чём?

Да блин. Читал читал - так ни хрена и не въехал - зачем разводить тредов больше чем процессоров? Я понимаю когда есть 128 процессоров - лепим 128 тредов. А когда один процессор?

aissp писал(а):мне вот что неясТТно. Что делать если время ответа недетерминировано. Представим, что система ищет собственный вектора для матриц, размер которых неопределен. Ежели ето 3 на 3 - да ради бога можно на селекте (на люьом диспатч механизме) а ежеди 5 на 5? ОК - в данной задаче можно определить по размерности матрицы время счета, хотя вру - юзер задал мартицу 10 на 10, но она блин диагональная - вектора мы ему сразу отдадим...

Для таких длительных операций есть такая неплохая идея (не моя):
- клиентский запрос : посчитать матрицу, матрица такая-то.
- сервер ответ : матрица большая; погодь маленько.
- клиент запрос ( в отдельном треде клиента в лупе с некоторым тамвайт) : уже посчитал?
- сервер ответ: почти, погодь.
- клиент запрос : уже посчитал?
- сервер ответ : да, вот результаты.

Так а я о чём?

Ну так вопрос изначально был - один тред или много. Твои парни предложили один, и ты с ними сейчас согласен.

Читал читал - так ни хрена и не въехал - зачем разводить тредов больше чем процессоров?

Молодой, зеленый еще

Во-первых, откуда ты знаешь, сколько там будет процессоров. Но это даже неважно, т.к. есть "во-вторых": кто сказал, что все обработчики выполняются с одинаковой скоростю, которая зависит только от скорости процессора? А если обработчик ждет ответа от БД, которая вообще на другом компе, то все должны его ждать?

Vovchik писал(а):Да блин. Читал читал - так ни хрена и не въехал - зачем разводить тредов больше чем процессоров? Я понимаю когда есть 128 процессоров - лепим 128 тредов. А когда один процессор?

Об этом сказано было. Два треда на одно устройство - идеальный вариант. Фактически получится чуть больше. Правильное решение, см, как ajkj2em делает. (выше в нитке)