Замечания о производительности сервера v.3.11



Posted by Анатолий Анимица on November 09, 1999 at 15:01:32:

In Reply to: О производительности сервера posted by Семенюк Виктор on November 08, 1999 at 22:00:49:

Виктор Семенюк пишет:
: Недавно поменял сервер 2.32 на 3.11 (на 2х пользователей).... Но реакция сервера на различные изменения и добавления операция уменьшилась в 10-30 раз. Для того, чтобы передать на сервер 2900 операций на сервер (испльзуя программу trancl) мне потребовалось более 5 часов. Даные передавались только за последний месец. ta-факты храню только за последний месяц. Количество операций немного более 36000.

Маловато данных, но, пожалуй, можно догадаться. Transcl передает серверу операции для регистрации - и среди них, надо думать, есть операции, генерирующие первичные документы. Сервер, получив очередную операцию, при вычислении своего нового состояния обнаруживает, что [stamp 3].des файл отсутствует, и пытается обновить [stamp 3].txa, которого, естественно, нигде нет, так как transcl передает только операции, а не сопутствующую информацию (не нужную для пересчета состояния да и для регенерации документа тоже). Генерация документа сама по себе не должна сильно замедлить актуализацию сосотяния сервера, но если в программе создания документа есть нерациональные куски - не заметные при единичной регистрации операции, при массовой отправке операций на сервер могут, конечно, привести к его замедлению против серверов 2.32 и 29H. Только нужно понимать, что они выполняют не одинаковую работу :)).

Похоже, нечто подобное происходит и в дискуссии, разгоревшейся днем ранее - я к ней еще вернусь, если здешний Интернет позволит. Неудачный алгоритм резко увеличивает потребные ресурсы при такой же или даже меньшей длине кода. Спросите у своего браузера над wwwboard, что такое "полиномиальная сложность" - (Ctrl+F) и эти слова - и он даст несколько ссылок на мои заметки, где поясняется, что увеличение потребных ресурсов в 4 раза при удвоении размера задачи обозначает, что алгоритм имеет квадратичную сложность ("N квадрат"), ну и так далее. С этой точки зрения один проход по массиву фактов и один проход по порожденному % массиву - это линейный (сложности 1) алгоритм, а N вхождений в цикл для N фактов - это, скорее всего, алгоритм N квадрат, и никакая оптимизация реализации в программе одной ветви алгоритма не скомпенсирует этого пагубного факта. Это блестяще проиллюстрировал Рустем Мухаметшин, но вышесказанное - пока предварительные замечания, я к ним надеюсь еще вернуться.

Если мне не удалось угадать причину - можно описать здесь или по E-mail свою реализацию, и я смогу ответить более конкретно.

А что делать в таких случаях? Если на время загрузки внешнего файла операций в автономном сеансе сервера отключить все "создать документ" в ветвях дерева (заменой cas.rul), то загрузка пройдет быстро. И штампы будут розданы операциям, и все такое. Если после этого вернуть cas.rul и рестартовать сервер, все первичные документы будут созданы в первом проходе сервера - за один раз, и это будет быстрее.

Я пока в Северодонецке, поэтому не очень доступен в Интернете, но - по мере сил и возможностей - я Ваш

С уважением
ААА


Пpишедшие ответы: