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/

Дати відповідь електронним листом