Нужно больше практики

Курсы курсами, а вот практики в решении проблем технологического характера очень не хватает. Возможно кто-то из вас сможет помочь с моей бедой. Поэтому решил провести эксперимент - прием заявок на диагностику проблем производительности. Для участия необходимо перейти по ссылке "Ускорение 1С" в шапке блога и зарегистрировать обращение.

Предполагается следующий формат:
- до четырех часов безвозмездной работы по вашей проблеме;
- основные работы будут проводиться по вечерам или в выходные;
- отчет будет опубликован в блоге.

Пока в планах отработать первые пять-семь заявок, дальше будет проведен анализ эффективности и востребованности подобного формата. Вопросы в комментариях приветствуются.

bash, еще bash, еще много-много bash

А на ловца и зверь бежит, коллеги. Буквально недавно эпизодически bash'ил подведомственный техжурнал и делал заготовки скриптов. И тут свершилось - двухнедельный проект по анализу текущих проблем производительности. Без ограничений не обошлось, в лучших традициях жанра. Конфигурация УПП 1.3 - соответственно, древняя БСП, где подсистема оценки производительности еще на перечислениях. На продуктив ходить только под присмотром, самостоятельно ничего не менять, ничего не запускать. ЦУП нельзя, как сказали, уже пробовали - сбор данных тормозит систему. Заказчик привел адекватные аргументы в пользу поставленных ограничений. В итоге, из доступных инструментов остались логи технологического журнала и счетчики производительности, которые складываются на отдельный тестовый сервер. Там же развернута копия базы. Если бы не скрипты, то тогда вообще непонятно бы было, что со всем этим делать.

Проблемы производительности. Фрагментация индексов.

Недавно на практике получилось увидеть влияние чрезмерной фрагментации индексов на производительность базы, конфигурация 1С: ERP. Ранее я читал, что излишняя фрагментация влияет на скорость выполнения операций INSERT, UPDATE, DELETE, в чем и удалось убедиться. Как обычно бывает, проблему обрисовали в общих чертах - у клиента тормозит база. В таких случаях, когда не известно, с чего начать - начинаем с настройки сбора данных по счетчикам производительности и технологического журнала. В моем случае анализ данных по счетчикам производительности проблем загруженности оборудования не выявил. Так же в существующие настройки техжурнала была добавлена секция для сбора событий с длительностью, превышающей три секунды.

А ты включил режим "high perfomance"?

Нашел на днях свой прошлогодний отчет для клиента о произведенных настройках сервера. Обратились с проблемой: после перехода с файловой типовой бухгалтерии (до десяти пользователей одновременно) на клиент-сервер начались тормоза. В частности, время восстановления последовательности увеличилось раз в пять. За что, спрашивается, заплатили?
Отдельно стоит выделить настройку управления питанием сервера. Делается просто, но как ни странно, про нее часто забывают. Все последние сервера, которые приходилось дополнительно настраивать, работали со схемой "по умолчанию". Поэтому выкладываю результаты замеров производительности из этого отчета, как аргумент в пользу того, что не стоит пренебрегать данной настройкой.

Excel Fast Massive Load

Какие бы ни были большие по объему импортируемые данные, всегда хочется, чтобы они грузились как можно быстрее. Иначе зачем нам тогда эти хх-ядерные компьютеры с уу-гигабайтами оперативы. Для Excel в качестве альтернативы классическому медленному последовательному обходу по ячейкам листа можно использовать считывание данных в память с последующей обработкой.
Сначала мы так же подключаемся через COM-соединение к необходимому файлу и получаем нужный лист с данными. Далее, обращаемся к свойству листа .UsedRange.Value. Это свойство содержит значение типа COMSafeArray, с котором 1С умеет работать и в котором как раз и находятся все необходимые нам данные. Через метод Выгрузить() получаем наши данные и обрабатываем их. В качестве примера приведу обработку и замеры по быстродействию.

Кэширование изображений

При работе в клиент-серверном варианте между базой и пользователем могут ходить большие объемы данных, носящие справочный характер, например, сохраненные в базе или подгружаемые со стороны сервера изображения, документы. Часть этих данных можно помещать в кэш на стороне пользователя, чтобы уменьшить нагрузку на базу. В частности, можно использовать для кэша коллекцию Соответствие.

Рассмотрим на примере простой конфигурации, которая содержит справочник "Контрагенты" и подчиненный ему справочник "Файлы контрагентов". Справочник "Файлы контрагентов" содержит реквизит ХранилищеИзображения, тип ХранилищеЗначения. Эти данные мы и будем кэшировать при обращении.

Оптимизация 1С

Допустим, нам необходимо посмотреть, как можно ускорить формирование отчета. Мы запускаем отладчик, включаем замер производительности, находим слабые места и оптимизируем код/запрос. Сделали, в тестовой базе результаты устраивают, а в действующей базе опять медленно. А у нас, оказывается, файловая БД и с ней 20 пользователей работают по сети, и тормоза наблюдаются не только в отчете, но и в работе с базой в целом. В этом случае ситуацию можно разрешить, перенеся базу на связку Сервер 1С + СУБД, MS SQL например. Но, чем больше подключений к базе, тем больше необходимо уделять внимание оптимизации не только кода, но и производительности серверной части и организации СУБД.