Что такое производительность 1С

В нашей практике часто бывает так, что клиент не может самостоятельно сформулировать проблемы производительности. Как ему помочь?
Реальные клиенты не читали книжку 1С-Эксперт, ни один нормальный руководитель при решении этой задачи никогда не будет читать пункт 2.4 данной книжки, который называется “Бизнес-процесс решения проблем по ключевым операциям”.
Прежде чем начать что-то исправлять – надо сначала помочь клиенту сформулировать свои желания в критериях, которые можно объективно измерить. Есть огромное желание не делать данный пункт, пропустить его, так как он не кажется важным. И только многократный реальный печальный опыт может нас в этом переубедить, что мы вам дальше и покажем. Если нет объективных критериев – клиент (или пользователь клиента) всегда может потом сказать, что либо лучше не стало, либо сразу так хорошо было.
Есть другой ряд проблем, который менее очевидно и связан с формализмом при реализации данной методики.
Например, мы подпиской на все события проведения документов собираем статистику проведения данных документов. При анализе собранных значений, например по документу реализации товаров и услуг, может выясниться, что проведение этой операции имеет несколько явных пиков в районе 2 секунд, 10 секунд и 50 секунд. То есть ряд пользователей, как правило, видит время в районе 2 секунд, значительная часть пользователей видит время в районе 10 секунд, а часть в районе 50 секунд. При этом нельзя сказать, что такое разное поведение связано с конкретными пользователями. Одна из проблем, которая возникает при формализме, связана с нежеланием вникать в детали. Например, скорость может сильно зависеть от количества строк в табличных частях документа. Логично будет ожидать, что документ с десятком строк в ТЧ будет проводиться в течение нескольких секунд, в то время как 9000 строк вряд ли проведутся за то же время.
Конечно, бизнес может не различать объём или количество строк в ТЧ и для него критична любая операция, которая длится более пяти секунд, так как по каким-то специфичным особенностям бизнеса более долгая операция может приводить к возникновению убытка. Но в любом случае, в поиске решения нам придётся показать бизнесу, что решение напрямую связано с составом ТЧ и количеством строк в ней.
Хотелось бы пару фраз рассказать о выражении «плохой код»: разные пользователи информационной системы давать оценку качеству кода могут диаметрально противоположную. Настоящей дилеммой является выбрать приоритеты между скоростью работы каждого конкретного пользователя, или их одновременной коллективной работе и взаимодействием друг с другом. Одни задачи требуют максимальной производительности в рамках одного потока, например какая-то массивная загрузка данных, расчёт себестоимости. Другие задачи требуют аккуратного, не чрезмерного обращения к данным, неиспользование всех аппаратных ресурсов, чтобы обеспечить возможность коллективной работы в одной информационной системе на одном сервере всех пользователей. Далеко не всегда можно например сказать, что квотирование ресурсов целесообразно для решения однопоточной задачи, где важно как можно быстрее получить результат. Возникает необходимость на уровне бизнеса расставить приоритеты. Будет ли эта однопоточная задача важнее коллективной работы, или эта работа важнее однопоточной задачи.
Вот на слайде приведён пример однопоточной задачи, которая важнее коллективной работы.
Ещё один яркий пример неоднозначности того, что можно считать плохим кодом, является алгоритм партионного учёта (ФИФО/ЛИФО). Данный алгоритм может быть реализован различными способами, но при этом изначально задача партионного учёта для правильной работы требует монопольного захвата конкретной партии. С точки зрения алгоритма и целостности данных не могут два пользователя одновременно изменить информацию о партии. Однако, если подходить к этому вопросу с позиции коллективной работы, то должно быть очевидным, что требования алгоритма изначально являются плохими для обеспечения коллективной работы в этой информационной системе. На фоне выше сказанного можем привести пример реального кода, когда параллельность попираться совсем. В документах двигающих остатки в комплексной конфигурации перед тем как “свернуть резервы” накладывается блокировка на константу. У любой организации, у любых пользователей которые между собой не пересекаются блокировка все равно будет. Потому что блокируется константа — одна конкретная запись для любых документов данного вида, не зависимо от аналитики. И даже если такие документы будут быстро проводится, то о полноценной параллельности такого кода говорить не приходится, параллельности ввода данных нет.