1.3. Производительность приложения

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

приложения, а не каждого компонента в отдельности. На производительность распределенных приложений влияет множество факторов: оборудование, соединения, конфигурация системы, топология приложения и т.д., не зависящих от методов кодирования компонентов и приложений, При этом всегда возможен компромисс между простотой разработки, развертывания, сопровождения и эффективностью приложения. Главное при повышении производительности — с минимальными затратами найти и устранить «узкие» места в работе

приложения. При анализе производительности, особенно на ранних стадиях разработки проекта, редко удается точно воссоздать условия, в которых он будет эксплуатироваться.

Поэтому часто единственная возможность оценить производительность в реальной среде — экстраполировать результаты тестирования. Чем точнее тестовая среда воспроизводит эксплуатационную, тем ниже вероятность ошибки экстраполяции, однако затраты на

адекватное моделирование реальной среды иногда превышают выгоды от снижения риска некорректности результатов тестирования. Для достижения требуемой производительности желательно выполнить только действительно необходимую работу. Таким образом, проверить эффективность приложения — значит уменьшить риск того, что приложение не сможет поддерживать требуемый уровень производительности, а не повышать этот уровень до предельных значений