Опыт и трудности

"Группа разработчиков", так часто упоминавшаяся ранее, на момент начала проектных работ состояла из одного специалиста. Первой индивидуальной работой было проектирование ядра панели управления, ядра социальной сети, основных структуры данных и базовых таблиц БД. Базовые классы для контрольной панели были взяты практически неизменными из уже имеющихся наработок, структуры данных и таблицы БД тоже не вызвали затруднений - запланированная рабочая неделя была достаточна для этих работ. Некоторое недоумение вызывает довольно сложная для понимания схема шаблонов, однако функционально она гарантированно перекрывает все возможные потребности. Далее по одному в проект подключились три программиста, и программирование приобрело нормальный рабочий порядок.

Однако это успешное и беспроблемное движение вперед длилось весьма недолго. Если при разработке панели управления еще можно несколько вольно обращаться с производительностью, поскольку нагрузка от нее составляет доли процента от общей нагрузки, то ядро портала, формируюшее типовые страницы пользователей - такие как профиль или блог - должно показывать весьма высокую производительность, малое время отклика и главное - не должно генерировать высокую вычислительную нагрузку на базу данных. Предварительные стресс-тесты, проведенные на почти голых страницах основного наполнения портала показали, что с предложенной архитектурой не все ладно. Или точнее, совсем все плохо: тестовый сервер показал едва-ли десять ответов в секунду, и это при том, что страницы практически не содержали информационной обвязки (данных авторизованного пользователя, признак наличия новых сообщений, анонсы новостного и рейтингового блоков, облако тегов).

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

С каждым днем исследований и дебатов по их результатам становился все более очевидным тот факт, что из первоначальной архитектуры желаемых параметров производительности не выжать никакими ухищрениями. Интересно было наблюдать, как архитектор шаг за шагом под давлением аргументов сдавал свои позиции и в конце концов признал полную несостоятельность исходного варианта и согласился на полную переработку архитектуры. Решение принималось руководителем проекта и результаты исследований, включая прогнозы и рекомендации всех вовлеченных сторон, были переданы ему для принятия окончательно решения.

Дата добавления: 2015-10-29