On Fri, 23 Jan 2004, Sergei Golod wrote:
> Об этом тайваньцы тоже пишут. То 1000/секунду, то не более 100.
> Игорь, вы их жалобы как-то прокомментируете? :)
Таких эффектов, как описывают тайваньцы я не наблюдал никогда. Если узнаю,
в какой ситуации это появляется - буду исправлять. С их рекомендацией
использовать то, что работает - согласен на 100%.
Я знаю о том, что есть проблемы производительности, связанные
1) с выбором модели thread-per-client
2) с неоправдавшейся надеждой на то, что можно обойтись без своей системы
распределения памяти
3) с реализацией тридов в некоторых ОС (точнее - с качеством этой реализации)
первую и вторую причины я устранил (в новой версии), третью - нет :)
вот что вижу в тесте с полиграфом на FreeBSD (большое спасибо Dmitry
Morozovsky за предоставленный стенд):
новая версия:
CPU states: 30.1% user, 0.0% nice, 14.8% system, 19.5% interrupt, 35.5% idle
Mem: 62M Active, 349M Inact, 65M Wired, 20M Cache, 60M Buf, 4372K Free
Swap: 1024M Total, 40K Used, 1024M Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
47883 igor 43 0 47852K 32248K RUN 0:59 52.05% 52.00% oxy
oops:
CPU states: 49.8% user, 0.0% nice, 26.5% system, 22.6% interrupt, 1.2% idle
Mem: 57M Active, 348M Inact, 65M Wired, 20M Cache, 60M Buf, 8752K Free
Swap: 1024M Total, 40K Used, 1024M Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
47889 igor 62 0 113M 26948K RUN 1:31 96.77% 96.44% oops
Темп запросов в этих случаях одинаков, типа:
req. delay clients
rate connected
------ ---- ---
001.49| i-dflt 35047 394.93 2233 0.00 0 840
001.57| i-dflt 37271 422.83 1876 0.00 0 840
001.66| i-dflt 39647 472.35 1798 0.00 0 840
001.74| i-dflt 42137 498.00 1860 0.00 0 840
001.82| i-dflt 44225 416.78 1896 0.00 0 840
При этой нагрузке процессор на машине с полиграфовским клиентом занят на
100%, поэтому большего темпа запросов достичь не удастся.
Судя по тому, что новая версия жрет меньше cpu(почти в два раза, при этом
oops практически сьел весь CPU), хочу надеятся что она работает быстрее.
Будет аналогичный стенд на солярке/линуксе - проверю. Пока стенда нет -
проверяю на домашней машине... То что вижу можно описать так: при
небольшом числе одновременных соединений новая версия работает медленнее
(примерно 480req/sec против 520req/sec при 30 клиентах) в основном на счет
большей задержки на обслуживание одного запроса (примерно 62мс против 58мс).
при большом числе одновременных подключений скорость сравнивается, но при
этом машина загружена уже на 100% и резальтаты эти не очень валидны.
Откуда берется разница во времени на обслуживание запроса я знаю и
постепенно эта разница становится всё меньше.
Должен сказать, что в новой версии многое делается НАМНОГО правильнее чем в
старой, ну по крайней мере мне так кажется (если кто поправит - буду очень
благодарен).
Igor Khasilev |
PACO Links, igor at paco dot net |
=====================================================================
If you would like to unsubscribe from this list send message to
[EMAIL PROTECTED] with "unsubscribe oops" in message body.
Archive is accessible on http://lists.paco.net/oops-rus/