Что-то с утра пораньше задался вопросом по AB. Есть сайт. Генерируется за 0.02-0.035 сек. Используется Nginx => Apache, PHP 5.3 => PGBouncer => PostgreSQL. Делаю ab -n 1000 -c 10 http://example.com/ получается 160 запросов в сек. Время генерации сайта не существенно возрастает. Делаю ab -n 1000 -c 100 http://example.com/ получается 36 запросов в сек. Время генерации сайта вырастает до 1.6-2 сек. Время на базу не тратится, возрастает время работы PHP. В top 75 %system остальное %user, в основном всё занимает Apache. Я немного не могу понять, в чём для Апача разница между 10 одновременными запросами и 100? Ведь Nginx общается с ним через HTTP/1.0, где каждый новый запрос - это новое подключение. Почему тогда уменьшается число запросов в сек? По идее же, если при 10 одновременных запросах он пишет 160, то при ста одновременных тоже должно быть 160? Конечно, я скорее всего не до конца понимаю значение опции -c, но вроде это во сколько потоков опрашивать сервер и получается, что нагрузку от большого количества потоков должен брать на себя Nginx, а Apache не должен замечать.
Так Апачу всё равно сколько потоков. Ему важно количество запросов. Остальное делает Nginx. Сейчас любопытство меня извело сильнее. В итоге проблема, как я понял, оказалась в scalaxy. Так как протестировал это на выделенном серваке друга и оказалось 100 запросов в сек выполняется стабильно вне зависимости от -c опции.
Не все равно, потоки то его. создание/запуск/синхронизация/уничтожение потока стОят ресурсов, именно поэтому (минимум под виндой) не делают серверные части для многоюзеров с одним потоком на коннект (хотя это проще всего сделать) - сдохнет при большом кол-ве потоков, потому что их обслуживать надо.
не знаю как под никсами, под виндой я писал очень много многопоточных приложений, занимался их оптимизацией в том числе. накладные расходы на создание и закрытие потока микроскопические - за секунду можно выработать на спящие потоки все доступные дескрипторы. при желании, их можно так же освободить. только сама система забирает их уже не так охотно. в этом и проблема. под линуксом я тонкостей не знаю, но уверен, проблема с тормозами если и есть, то лежит скорее всего тоже где-то в плоскости описателей потоков. для системы 10000 работающих потоков проблема только отчасти. однородные процессы образуют группы и продолжительность кванта увеличивается, для того чтобы уменьшить накладные расходы. винда, к примеру, может увеличивать квант на группу до 50мс. учитывая, что переключение внутри группы происходит без синхронизации, т.е. можно считать - мгновенно, а между группами где-то 500-700нс, то накладные расходы на переключение составляют где-то 0,2%. весомым аргументом может оказаться то, что объем обрабатываемой памяти не влазит в кэш второго уровня. на бенчмарках вы запрашиваете одну и ту же страницу и оперативную информацию кэширует проц (хорошо видно на уровне конвееров, если закопаться) и то, при подготовке данных или при однородности данных. часто при многопоточном запросе в кэш так или иначе на каком-никаком уровне попадает много разделяемых данных. в реальности же (не при тестах) разделяемой при такой тонкой синхронизации (50мс) информации не будет. придётся выгружать и вгружать в кэш порции памяти даже внутри группы, т.е. весь выйгрыш на отсутствии по синхронизации дескрипторов мы просрали. получаем в реальности, что бенчмарки в случае многопоточности не дают реально картинки, какие бы вы ключи туда не совали
antonn, зря хаишь винду. она в плане синхронизации крутая. иначе бы она сейчас отсасывала с проглотом у юниксов. проблема винды в постоянном подтекании памяти, хреновой постановке приоритетности процессов (хочу даю процессу с приоритетом 31-16, захочу - заберу и отдам тем, у кого 15-1) и армии бесполезных демонов, которые опрашиваются по делу и без. но в плане низкоуровневой оптимизации они очень быстро впивается во все возможности процессоров и использует самые крутые низкоуровневые команды почти во всех жизненно важных компонентах. мы еще только раскуривали работу с TBB (одни из первых в СНГ, и были одними, кто был допущен к тестированию от Intel), а через три месяца они уже внедрили. это мега круто! но это пожалуй то немногое, что держит винду наплаву. они не рефакторят код. они просто его компилят заново на новых библиотеках, которые делают низкоуровневый рефакторинг без вмешательства человека. с другой стороны, если дать эти технологии *nix-подобным системам, обеспечив такое тесное взаимодействие с железом, они бы улетели лет на 10 вперед ЗЫ: за последний год я воспользовался виндой раз 15, наверное. но это не даёт мне права говорить, что винда говно, потому что она винда. у всего есть свои плюсы.