постоянно сталкиваюсь с персонажами, которых я про себя называю "любители потоков". Этих людей отличает то что они для любой функциональности считают нужным заводить отдельный поток. И ладно еще если этих потоков будет гораниченное число-например поток на работу с сетью, поток на работу с БД. Бывает так что скажем хочет человек написать web-сервер и говорит-а дай ка я на каждое соединение заведу себе поток. Потом следуя своей стратегии, на каждое соединение заводится 2,3 и так далее потоков. Таким образом получается что при скажем 1000 соединений в системе будет 1000*n потоков. Кто что думает по этому поводу, и есть ли тут такие любители потоков?
Здравствуйте, sluge, Вы писали: S>а если с++ или жаба?
Мой поинт в том, что с философской точки зрения большое количество "потоков" — вполне нормальный подход.
Понятное дело, что для такого подхода нужно выбирать соответствующие средства реализации. Будь то green threads или грамотно используемый пул потоков.
Здравствуйте, sluge, Вы писали:
S>постоянно сталкиваюсь с персонажами, которых я про себя называю "любители потоков". Этих людей отличает то что они для любой функциональности считают нужным заводить отдельный поток. И ладно еще если этих потоков будет гораниченное число-например поток на работу с сетью, поток на работу с БД. Бывает так что скажем хочет человек написать web-сервер и говорит-а дай ка я на каждое соединение заведу себе поток. Потом следуя своей стратегии, на каждое соединение заводится 2,3 и так далее потоков. Таким образом получается что при скажем 1000 соединений в системе будет 1000*n потоков. Кто что думает по этому поводу, и есть ли тут такие любители потоков?
А что, тут какие-то варианты мнений что ли есть? Если у людей нет желания написать масштабируемый сервер массового обслуживания — то пусть делают как хотят. Некоторые и вообще удовлетворяются одноклиентными серверами.
А если есть желание написать сервер, который будет держать хотя бы десятки тысяч клиентов, то, конечно же, выделять отдельный поток на соединение нельзя.
Вообще, интересно, где это вы "постоянно сталкиваетесь" с такими персонажами.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
В С++, особливо на виндах, — проблема. Стек на 1000 процессов выест 1000 * 10 Мб (по дефолту) = 10 Гб виртуальной памяти, в 32 бита (2 Гб предел) уже не лезет. Проблема реально существует, мы с ней боролись. Сначала уменьшением аппетитов (до 1 Мб стека), потом стало понятно, что делу это не поможет и консолидировали потоки. Стало намного лучше работать.
Здравствуйте, SkyDance, Вы писали:
S>>а если с++ или жаба?
SD>В С++, особливо на виндах, — проблема. Стек на 1000 процессов выест 1000 * 10 Мб (по дефолту) = 10 Гб виртуальной памяти, в 32 бита (2 Гб предел) уже не лезет. Проблема реально существует, мы с ней боролись. Сначала уменьшением аппетитов (до 1 Мб стека), потом стало понятно, что делу это не поможет и консолидировали потоки. Стало намного лучше работать.
МСДН говорит 1 мегабайт по умолчанию на поток:
The default size for the reserved and initially committed stack memory is specified in the executable file header. Thread or fiber creation fails if there is not enough memory to reserve or commit the number of bytes requested. The default stack reservation size used by the linker is 1 MB. To specify a different default stack reservation size for all threads and fibers, use the STACKSIZE statement in the module definition (.def) file. The operating system rounds up the specified size to the nearest multiple of the system's allocation granularity (typically 64 KB). To retrieve the allocation granularity of the current system, use the GetSystemInfo function.
Хотя это конечно не повод плодить по потоку на коннекшн А если сильно хочется — то легкие потоки.
Здравствуйте, SkyDance, Вы писали:
SD>В С++, особливо на виндах, — проблема. SD> Стек на 1000 процессов выест 1000 * 10 Мб (по дефолту) = 10 Гб виртуальной памяти, в 32 бита (2 Гб предел) уже не лезет.
А при чем тут вообще С++?
CreateThread — WinAPI функция, которой можно задавать отличный от дефолтного размер стека.
SD> Проблема реально существует, мы с ней боролись. Сначала уменьшением аппетитов (до 1 Мб стека), потом стало понятно, что делу это не поможет и консолидировали потоки. Стало намного лучше работать.
Можно было попробовать еще на Fiber-ы перенести, некоторым помогало.
Здравствуйте, Sinclair, Вы писали:
S>А что, тут какие-то варианты мнений что ли есть? Если у людей нет желания написать масштабируемый сервер массового обслуживания — то пусть делают как хотят. Некоторые и вообще удовлетворяются одноклиентными серверами. S>А если есть желание написать сервер, который будет держать хотя бы десятки тысяч клиентов, то, конечно же, выделять отдельный поток на соединение нельзя.
Всё зависит от того, что должен делать этот сервер. В некоторых случаях может оказаться оправданным и выделение по процессу на соединение — в том числе и для масштабируемых сервисов с десятками и сотнями тысяч клиентов.
А вообще мой пойнт такой, что в даже рамках одного проекта могут быть разные сервера с разными потоковыми моделями.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, Sinclair, Вы писали:
S>А если есть желание написать сервер, который будет держать хотя бы десятки тысяч клиентов, то, конечно же, выделять отдельный поток на соединение нельзя. S>Вообще, интересно, где это вы "постоянно сталкиваетесь" с такими персонажами.
Ща рассмешу: здесь
Здравствуйте, SkyDance, Вы писали:
SD>Старые legacy, когда там уже мегатонны древючего кода намучены, рефакторить в таком объеме было просто "ссыкотно" (С).
В чем тогда заключалось "консолидировали потоки" ? и почему это было менее "ссыкотно" (С)
Здравствуйте, SkyDance, Вы писали:
SD>Потому что в жабе потоки сразу обычно легковесные — и без всяких CreateThread.
Видимо потому, что они не совсем потоки. Вернее не OS потоки.
SD>Старые legacy, когда там уже мегатонны древючего кода намучены, рефакторить в таком объеме было просто "ссыкотно" (С).
+1
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, SkyDance, Вы писали:
SD>>Потому что в жабе потоки сразу обычно легковесные — и без всяких CreateThread. CC>Видимо потому, что они не совсем потоки. Вернее не OS потоки.
В яве зелёные потоки были насколько мне помнится только в 1.1.
J>В чем тогда заключалось "консолидировали потоки" ? и почему это было менее "ссыкотно" (С)
Проект старый, начат был малоквалифицированными людьми. Каждый громоздил свой слой абстрации от чего-нибудь, и дописывал наслоения кода. Так вот, при таком количестве кода нетрудно было найти точки диспетчеризации для наиболее типичных задач, которые порождали наибольшее количество потоков. Соответственно, часть потоков стала консолидироваться через один диспетчер. Это позволило нам расширить поддержку многосерверных инсталляций до нескольких сотен серверов. До этого, когда был thread per server, мы были ограничены примерно 130 серверами в постоянном мониторинге. И в целом, когда мы проводили исследования, даже при сниженном объеме стека до 256 кб у нас не создавалось больше 190 потоков. То ли из-за фрагментации памяти, то ли еще почему, но — факт.
Решение, конечно, местечковое. Но именно такие и принимаются во время maintenance продукта — никто не будет проводить глобальный рефакторинг, если это не принесет реальных бенефитов.
Здравствуйте, SkyDance, Вы писали:
S>>а если с++ или жаба?
SD>В С++, особливо на виндах, — проблема. Стек на 1000 процессов выест 1000 * 10 Мб (по дефолту) = 10 Гб виртуальной памяти, в 32 бита (2 Гб предел) уже не лезет. Проблема реально существует, мы с ней боролись. Сначала уменьшением аппетитов (до 1 Мб стека), потом стало понятно, что делу это не поможет и консолидировали потоки. Стало намного лучше работать.
Здравствуйте, Sinclair, Вы писали:
S>А если есть желание написать сервер, который будет держать хотя бы десятки тысяч клиентов, то, конечно же, выделять отдельный поток на соединение нельзя.
IIS вроде бы выделяет, но все им пользуются тем не менее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>IIS вроде бы выделяет, но все им пользуются тем не менее.
Ну конечно же ничего он не выделяет. Он использует IO Completion Ports и пул потоков.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, sluge, Вы писали:
S>постоянно сталкиваюсь с персонажами, которых я про себя называю "любители потоков". Этих людей отличает то что они для любой функциональности считают нужным заводить отдельный поток. И ладно еще если этих потоков будет гораниченное число-например поток на работу с сетью, поток на работу с БД. Бывает так что скажем хочет человек написать web-сервер и говорит-а дай ка я на каждое соединение заведу себе поток. Потом следуя своей стратегии, на каждое соединение заводится 2,3 и так далее потоков. Таким образом получается что при скажем 1000 соединений в системе будет 1000*n потоков. Кто что думает по этому поводу, и есть ли тут такие любители потоков?
Ежу понятно:)), что всё зависит от задачи. И от среды.
Есть примеры, когда подход "одна нить на клиента" приводила к переполнению ресурсов — например, oops (конкурент squid'а) выдерживал более 2000 клиентов только на солярке, а на более "народных" ОС дох значительно раньше. Соответственно, он далеко не ушёл.
Но чем сложнее обработка и чем меньше клиентов, тем проще и осмысленнее делать по нити на клиента и даже по несколько нитей на клиента.
