Я недавно работал над проектом,

Я недавно работал над проектом, в котором проектировщики придумали очень элегантную архитектуру. Клиент с помощью Web-браузера взаимодействовал по протоколу HTTP с сервером приложений, обеспечивающим поддержку Java Server Pages (JSP). Алгоритмы работы приложения целиком генерировались инструментальными средствами и реализовывались в виде компонентов EJB (с использованием постоянного хранения на базе контейнеров), причем физически они выполнялись другим сервером приложений. В базе данных хранились только таблицы и индексы.

Итак, мы начали с технически сложной архитектуры. Для решения задачи должны взаимодействовать друг с другом четыре компонента. Web-браузер получает страницы JSP от сервера приложений, который обращается к компонентам EJB, а те, в свою очередь, — к СУБД. Для разработки, тестирования, настройки и внедрения этого приложения необходимы были технически компетентные специалисты. После завершения разработки меня попросили оценить производительность приложения. Прежде всего я хотел узнать подход разработчиков к СУБД:

где, по их мнению, у приложения могут быть узкие места, точки потенциальных конфликтов?

каковы, по их мнению, основные препятствия для достижения требуемой производительности?

Они не имели ни малейшего представления об этом. На вопрос о том, кто поможет мне переписать код компонента EJB для настройки сгенерированного запроса, ответ был следующий: "О, этот код нельзя изменять, все надо делать в базе данных". То есть, приложение должно оставаться неизменным. В этот момент я был готов отказаться от работы над проектом — ясно, что заставить это приложение нормально работать невозможно:

приложение было создано без учета масштабирования на уровне базы данных;

приложение нельзя настраивать и вообще изменять;

по моему опыту, от 80 до 90 процентов всей настройки выполняется на уровне приложения, а не на уровне базы данных;

разработчики не представляли себе, что делают их компоненты с базой данных и где искать потенциальные проблемы.

Содержание Назад Вперед