ONK
Пассивист PHPСluba
fisher, на реальном окружении протестировать не могу, да и результаты будут нестабильные.
Если рассматривать сервер чата, то даже на отдельно выделенном сервере, без сторонних приложений (только чат и его обвеска), доля демона чата в использовании ресурсов процессора при его условной 100% загрузке чатом, составит не более 5% (а скорее гдето 1%). Это в принципе не является узким местом чата, узким местом является отработка клиентских команд, поступающих на обычные скрипты. Надеюсь, что понятно написал.
В случае с рассылкой зашифрованных файлов, предполагаемая доля в общей нагрузке на процессор ещё меньше, т.к. задача просто разослать эталонные экземпляры файлов по множеству подключающихся клиентов.
Я не вижу в чём по уму прав MiksIr, для данной конкретной области ПХП почти идеальный вариант, к перечисленным плюсам добавлю достаточность его производительности для решения очень многих задач.
MiksIr, велосипеды тоже нужны, особенно удобные и хорошие. Меня в последнее время начинают раздражать товарищи, использующие невпопад это выражение.
По поводу чем не устроило. Я не рассматривал вариант с nginx, рассматривал вариант с Апачем + SSL недостатки просты, на каждое соединение копия апача (можно не рассматривать для 2-го и nginx) + копия ПХП интерпретатора, плюс издержки на парсировку скрипта (если без кэширования байткода).
Плюсы демона - все соединения в одном процессе, можно раздавать один файл сразу всем клиентам, теоретически полностью избавившись от дисковых операций (на практике у меня раздаются индивидуальные порции по 100кб). Минимальное использование памяти и процессорных ресурсов.
По поводу не эффективности select вызова, в данном приложении она не проявляется, т.к. в select передаются только сокеты из очереди чтения или записи, и ничего лишнего. При этом чтение ограничивается заголовком протокола, и обычно в очереди на чтение не больше 10 сокетов. А очередь на запись достаточно эффективно обрабатывается и сокращается по мере отправки. 95% select вызовов приходится с единственным сокетом на приём новых соединений.
Теперь по поводу тестов.
Протестировал на двух серверах.
Тестировал апач на запросы файла 0-й длинны (Апач очень тормозит на запросах не существующих документов).
Тестировал демон чата, т.к. он понимает http протокол и отдаёт понятные для ab ответы. Демон сервиса рассылки файлов протестировать ab не получилось, а по тесту из тестового скрипта он на 15% быстрее демона чата.
Первый сервер очень древний, с процом IP3-700
Апач 260 - 270 запросов в секунду
Демон чата 103 - 115 запросов в секунду
Второй сервер с процом IC2D 2ГГц
Апач 2200 - 2280 запросов в секунду
Демон чата 1240 - 1270 запросов в секунду
Самая тормознутая часть демона чата - парсировка протокола, значительная часть которой производится на голом ПХП.
Если рассматривать сервер чата, то даже на отдельно выделенном сервере, без сторонних приложений (только чат и его обвеска), доля демона чата в использовании ресурсов процессора при его условной 100% загрузке чатом, составит не более 5% (а скорее гдето 1%). Это в принципе не является узким местом чата, узким местом является отработка клиентских команд, поступающих на обычные скрипты. Надеюсь, что понятно написал.
В случае с рассылкой зашифрованных файлов, предполагаемая доля в общей нагрузке на процессор ещё меньше, т.к. задача просто разослать эталонные экземпляры файлов по множеству подключающихся клиентов.
Я не вижу в чём по уму прав MiksIr, для данной конкретной области ПХП почти идеальный вариант, к перечисленным плюсам добавлю достаточность его производительности для решения очень многих задач.
MiksIr, велосипеды тоже нужны, особенно удобные и хорошие. Меня в последнее время начинают раздражать товарищи, использующие невпопад это выражение.
По поводу чем не устроило. Я не рассматривал вариант с nginx, рассматривал вариант с Апачем + SSL недостатки просты, на каждое соединение копия апача (можно не рассматривать для 2-го и nginx) + копия ПХП интерпретатора, плюс издержки на парсировку скрипта (если без кэширования байткода).
Плюсы демона - все соединения в одном процессе, можно раздавать один файл сразу всем клиентам, теоретически полностью избавившись от дисковых операций (на практике у меня раздаются индивидуальные порции по 100кб). Минимальное использование памяти и процессорных ресурсов.
По поводу не эффективности select вызова, в данном приложении она не проявляется, т.к. в select передаются только сокеты из очереди чтения или записи, и ничего лишнего. При этом чтение ограничивается заголовком протокола, и обычно в очереди на чтение не больше 10 сокетов. А очередь на запись достаточно эффективно обрабатывается и сокращается по мере отправки. 95% select вызовов приходится с единственным сокетом на приём новых соединений.
Теперь по поводу тестов.
Протестировал на двух серверах.
Тестировал апач на запросы файла 0-й длинны (Апач очень тормозит на запросах не существующих документов).
Тестировал демон чата, т.к. он понимает http протокол и отдаёт понятные для ab ответы. Демон сервиса рассылки файлов протестировать ab не получилось, а по тесту из тестового скрипта он на 15% быстрее демона чата.
Первый сервер очень древний, с процом IP3-700
Апач 260 - 270 запросов в секунду
Демон чата 103 - 115 запросов в секунду
Второй сервер с процом IC2D 2ГГц
Апач 2200 - 2280 запросов в секунду
Демон чата 1240 - 1270 запросов в секунду
Самая тормознутая часть демона чата - парсировка протокола, значительная часть которой производится на голом ПХП.
