>>Кстати эта проблема освещена на страничке посвященной проблеме C10K
>Так это проблема дизайна.
Ну да, ну да... а может, в итоге программирование производительного сервера под 32-битную платформу страдает тупым ограничением на стиль программирования на ровном месте?>Белые люди давно подметили, что в подобных задачах проблема часто сводится
>к тому, что держать хоть наполовину надутый инстанс на каждый чих --
>не надо, и стали разделять задачи приёма соединений и отработки приложения в разные слои.
От себя замечу что по идее, многопоточный сервер лучше масштабируется на многопроцессорных платформах.Особенно если скажем файлы из hot cache выуживаются(что при достаточном объеме памяти вполне возможно и здорово поднимает скорость работы).И будущее - за многопроцессорными машинами, большим объемом памяти и т.п. - вот тут еще вопрос кто окажется эффективнее...
>Любимый пример -- тот же nginx, который легко и непринуждённо принимает 10K
>коннекшенов (есть и другие, например, мультиплексирующий boa)
Юзаю для приватной файлопомойки lighttpd - насчет 10 000 конекшнов специально не тестил, но кучку юзвергов на 100 мбитах сервит и не икает.Кушая полпроцента проца и пару мегов памяти :).Да, он тоже не стартует процессы и треды на каждый чих :)
>и не держит код для обработки запроса всё время от начала соединения до отваливания
>(что на медленных соединениях сильно поднимает произведение время*RAM при
>использовании того же apache и для отработки соединений, и в качестве application
>server для всякого PHP/Perl).
Апач это да... memory hog :)
>заодно естественным образом "размазать" нагрузку на несколько бэкендов при необходимости.
Это да.Зато есть подозрения что без тредов нагрузка на процессоры 1 машины не очень размазывается.
>[в сторону:
>... зато гордо называется "ынтыпрайз солюшен"]
Я заметил что бизнес-дядек программеры нынче совсем за лохов держат, чуть ли не соревнуясь - кто более дерьмовое и ресурсожоркое решение за как можно больше денег втюхает :)
