Эпизод из повседневности

Работаю в офисе одного крупного клиента. За окном, естественно, небоскребы. На стене департамента "бизнес-интеллектуальности" - плакат одной консалтинговой конторы, показывающий, как весело и дружно идет работа в скрам-команде (scrum-team). Рядом висит список оффшорной команды, поставляющей, согласно картинке, некое приложение. Из 24 фамилий - 23 явно индусские.

Поработал с рабочим (production) сервером с чужого ноутбука, так с моего зайти напрямую через терминал нельзя. При этом можно без проблем подключиться к SQL Server. Окончил манипуляции, прав администратора нет, IOMeter не пашет. Ради интереса скопировал файл между логическими дисками сервера, посчитал, получилось около 14 Мб/сек. Это хуже, чем при чтении с переносного мини-винчестера. Челюсть уже не отвисает, когда ребята из системной поддержки бодро утверждают о 200 Мб/сек. Любопытно, что не в первой поддержке отвечают и не первый раз. Какая-то магическая цифра, видимо, вычитанная из руководств по промышленным дисковым массивам.

Ноутбук возвращаю, через 5 минут подходит сотрудник, спрашивает, можно ли закрыть "черное окошко", а то как-то непривычно. Подтверждаю, можно все закрыть.

Смотрим трассы загрузки экранов пользователей.

На первом - сотни коротких однотипных запросов, вырождающихся в 2 минуты ожидания. Ребята из скрум-команды не в курсе, что нужно выдергивать данные по возможности одним запросом. Подозреваю, они не в курсе, что и вложенные циклы как-то влияют на работу программ.

На втором - те же сотни, хотя поменьше. Но в начале - одна процедура, выполняющаяся полминуты. Лезу в исходник: 700 строк каши с использованием динамического запроса. План после очистки кеша выдает реальное время работы процедуры: 6 минут. В плане красуется проекция (view) - рефлексивное соединение (self join) относительно большой таблицы в... подзапросе. Пишу в диагноз. Пишу, как надо лечить. Дальше разбирайтесь сами на очередной "пионерской" скрам-линейке.