Продуктивність програми визначається його архітектурою

Ренді Стаффорд

На перший погляд здається, що це твердження має бути очевидним, але досвід реальної роботи показує зворотне Наприклад, архітектори програмного забезпечення нерідко вважають, що проблеми з продуктивністю програми можна вирішити простим переходом на програмну інфраструктуру від іншого виробника Джерелом цієї віри може бути рекламна галас навколо результатів тестування – наприклад, заявляється, що продукт фірми-лідера на 25% перевершує по продуктивності найближчого конкурента Однак якщо продукт-лідер виконує операцію за 3 мілісекунди, а конкуруючий продукт – за 4 мілісекунди, заявлені 25% (одна мілісекунда) значать дуже мало на тлі загальної низької продуктивності, що йде корінням в неефективність архітектури

Крім ІТ-менеджерів і команд тестування продуктивності є й інші групи людей, наприклад служба підтримки фірми-розробника і автори книг з управління продуктивністю додатків, які рекомендують зайнятися тонким налаштуванням інфраструктури програми: пограти з операціями виділення памяті, розмірами пулів підключень, розмірами пулів потоків і так далі Але якщо додаток спроектовано недостатньо ефективно для очікуваної навантаження або його функціональна архітектура нераціонально використовує обчислювальні ресурси, то ніяка тонка настройка не забезпечить бажаного швидкодії і масштабованості Буде потрібно повне перепроектування внутрішньої логіки та / або стратегії розгортання

У кінцевому рахунку за фасадом продукту будь-якого виробника і архітектури будь-якої програми діють одні і ті ж фундаментальні принципи розподіленої обробки даних і фізичні закономірності: додатки і використовувані ними продукти виконуються як процеси на компютерах обмеженої потужності, взаємодіючи один з одним через стеки протоколів і канали звязку з ненульовими затримками А значить, людям слід зрозуміти і прийняти думку про те, що архітектура додатка є головним чинником, що визначає його продуктивність і масштабованість Ці якісні характеристики неможливо поліпшити як за помахом чарівної палички – Чудодійною зміною технологій або тонким налаштуванням інфраструктури Будь-які удосконалення в цих областях вимагають наполегливої ​​праці по ретельного опрацювання архітектури

Ренді Стаффорд (Randy Stafford) – професіонал в області створення програмного забезпечення, що володіє 20-річним досвідом роботи в якості розробника, аналітика, архітектора, менеджера, консультанта і автора / лектора

В даний час займається розробкою проміжного (middleware) програмного забезпечення в складі групи А-Team фірми Oracle, а також бере участь у концептуальних проектах, займається оцінкою архітектури і допомагає усувати кризи виробництва різним організаціям в усьому світі Основні області його спеціалізації – сервіс-орієнтовані архітектури, продуктивність, висока доступність і JEE / ORM

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*