avl (avl) wrote,
avl
avl

Categories:

14. Архитектура определяет производительность

(В оригинале - Application architecture determines application performance)

Архитектура приложения определяет его производительность. Это утверждение кажется очень простым и очевидным, однако мировая практика показывает, что это не так. Например, проектировщики ПО часто верят в то, что для значительного прироста производительности достаточно простого перехода от одного бренда производителя к другому. Эта вера может быть вызвана разрекламированными результатами измерения производительности от вендора, обещающими, к примеру, на 25% лучшую производительность по сравнению с конкурентами. Но на самом деле, если к примеру продукт данного вендора выполняет одну операцию за 3 миллисекунды, а продукт конкурента – за 4 миллисекунды, то этот 25% выигрыш производительности (1 миллисекунда!) окажет очень несущественное влияние на конечную производительность всей системы, особенно если в проблемы производительности находятся в корне архитектуры системы.

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

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

Автор оригинала - Randy Stafford

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!
Tags: 97_things_architect_should_know, Программирование, Развитие
Subscribe

  • Один день на яхте

    Давно, очень давно хотелось оказаться на яхте. И вот наконец удалось реализовать мечту, пока что на 1 день. Главное — что оказалось, что никого из…

  • Подарок на 8 марта :)

    Фирма удивила, подарив 8 марта ВСЕМ сотрудникам смарт-часы от неизвестного производителя с нанесенным своим логотипом :) Да, в Словении 8 марта -…

  • Автомобильное...

    Ездишь себе, ездишь, стараешься машины поддерживать в исправном состоянии... А потом подходит очередной техосмотр - и машина вдруг впервые за 7 лет…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments