Содержание
Print 
PDFПримерно месяц назад у нас стали очень долго считаться отчеты. Не подскажете, что делать?
– Дорогой, когда я потягиваюсь, у меня щемит в левом боку. Что бы ты сделал на моем месте?
– Дорогая, на твоем месте я бы обратился бы к врачу.
Вряд ли существует универсальный рецепт, совет, следование которому позволит поднять производительность создания отчетов на порядки. Как мы помним, «каждая несчастливая семья несчастлива по-своему». Чтобы разобраться в конкретной ситуации, надо обратиться к специалистам – они поставят точный диагноз и помогут справиться с проблемой.
Мы приведем в качестве примера реальные способы, позволившие в живых проектах сократить время формирования отчетов в десятки, сотни и более раз. Надеемся, что такая статистика может быть полезна.
Админ – подход. Большому кораблю – большую торпеду
В некоторых случаях проблема решается довольно просто, без серьезной разработки и длительного анализа.
Исчерпались «ресурсы железа». Тонкое место может быть связано с узкими каналами передачи данных или производительностью сервера. Большинство современных систем организованы по технологии «клиент-сервер». А любой сервер (особенно SQL-сервер) кушает очень много оперативной памяти. Если решите обновить технику, обратите особое внимание на RAM. Часто простое увеличение оперативки с 8 до 16 Gb в сотни раз поднимает производительность.
Симптом «неожиданно отчеты стали считаться очень медленно» во многих случаях говорит о нехватке именно оперативной памяти. Может, и вам повезет – поставить дополнительную микросхему в сервер гораздо дешевле заказной разработки или реорганизации процессов учета. Хотя, часто такое решение является временным – если за год учетная система скушала 8 Gb оперативки, будьте готовы, что через полгода-год-полтора мало будет и 16 Gb.
Это страшное умное слово – индексы. Обычно большие и серьезные учетные системы настроены под использование конкретной базы данных. Однако, в заказных и самостоятельных разработках многие часто не тратят время и ресурсы на подобную оптимизацию. Попросите разработчика проверить индексы по часто используемым критериям запроса. Возможно, пять минут работы системного администратора сократят в десятки раз время расчета.
Будем надеяться, что вам повезет – дополнительная плата или 5 минут работы системного администратора на порядки поднимут производительность учетной системы.
Статистика показывает, что на каждый 10% повышения производительности «железом» или «средствами системного администратора» приходятся 90%, полученных реорганизацией самого процесса. Тем более, что «Админ-решения» обычно только откладывают проблему. Через год-два производительность, скорее всего, снова упадет. Реорганизация в некоторых случаях способна окончательно «закрыть вопрос».
Упомянем самые распространённые и эффективные приемы, хорошо зарекомендовавшие себя во многих проектах.
Слона едят по частям. Стоит ли нам требовать on-line?
Многие разработчики любят делать «все в одном». Один большой запрос по десятку таблиц, сводный отчет, перебирающий сотни тысяч первичных транзакций. Из совершенно непонятных соображений программисты стараются уменьшить число таблиц и процедур обработки данных, не думая о том, что такой подход сильно снижает производительность всего процесса.
Несколько лет назад подобный случай произошел с учетной системой сети розничных магазинов. В течение рабочего дня каждый магазин продавал около 200 позиций товара, выписывая примерно 30 тысяч чеков.
Итоговый отчет по продажам ежедневно анализировал эти 30 тысяч чеков, для каждой позиции считая себестоимость по довольно сложному алгоритму.
Естественно, через 3 месяца работы сервер стал тормозить – и ежедневные продажи стали рассчитываться 20-30 минут, затем час, два и более.
Был найден очень простой выход.
Сначала 30 тысяч чеков группируются в 200 записей по товарным позициям. Итоговый отчет – продажи и себестоимость строится не по 30 тыс транзакций, а всего по 200 записей. Естественно, время расчета сократилось с часов до нескольких секунд.
Более впечатляющих результатов можно достичь, отказавшись от принципа «on-line». Для подавляющего большинства учетных и управленческих задач не требуется оперативность «секунда в секунду». И финансовому директору и маркетингу и логистике вполне достаточно данных на вечер вчера. К тому же такой подход гораздо удобнее в текущей работе. Получив отчет по вчерашним данным, вы будете уверены, что цифры не поменяются через пять минут или полчаса, поскольку за это время кто-то успел внести новую накладную или исправить вчерашнюю.
Все необходимые группировки, расчет себестоимости и многое другое можно проводить в 2-3 часа утра. И с началом рабочего дня сводные отчеты будут строиться не часами, а меньше секунды.
Разделяй и властвуй
Ваша учетная система успешно работает 2, 3 месяца. Год, полтора. Ежедневно фиксируются тысяч и десятки тысяч транзакций. Базы растут – в таблицах уже миллионы записей и никакой сервер, никакие индексы не помогают. Отчеты считаются все дольше и дольше.
Подумайте, насколько нужен вам прошлогодний снег? Может, стоит убрать старые операции? В простом случае можно разделить базы, скопировав давно закрытые периоды в архив и оставив в оперативной только нужные операции.
Если у вас есть грамотный разработчик, можно поступить умнее. Можно выложить итоговые отчеты в репозитарий, а старые транзакции убрать в архив. Если пользователь обращается к закрытым периодам, отчеты не пересчитываются, а берутся из репозитария. Наиболее продвинутые системы позволяют даже расшифровывать все старые показатели до первички. Система анализирует период. Если рабочий – обращается к текущим данным. Для закрытого – берет расшифровки из архива.
Пользователь даже не заметит, что прошлогодние данные убраны в архив – все отчеты и все расшифровки оперативно создаются за доли секунды.
Подведем итоги
- Резкое падение производительности в большинстве случаев не требует перехода на новую учетную систему. В каждом конкретном случае лучше проконсультироваться с профессионалами, но часто проблему можно решить сравнительно небольшими ресурсами
- Иногда помогают простые решения. Возможно, добавив одну микросхему оперативной памяти или проиндексировав 3-5 рабочих таблиц, вы в десятки раз увеличите производительность. Будьте внимательны – часто такие решения лишь откладывают проблему. Возможно, через год – два производительность опять существенно упадет.
- Грамотный профессионал практически всегда может провести реинжиниринг вашей учетной системы, обеспечив повышение производительности в сотни и тысячи раз.
