Стратегії масштабування для додатків ASP.NET, Різне, Програмування, статті

Як радників по продуктивності ASP.NET нас зазвичай привертають до проекту, коли проблеми вже виникли. У багатьох випадках, виклик приходить тільки тоді, коли програма вже у виробництві. Те, що працювало відмінно для розробників, не працює для користувачів. Скарга: веб-сайт працює дуже повільно. Керівництво хоче знати, в чому причина і чому її не виявили при тестуванні. Розробники не можуть відтворити проблему. По крайней мере, одна людина стверджує, що ASP.NET не масштабується. Звучить знайомо?

Деякі з найбільш навантажених веб-сайтів у світі працюють на ASP.NET. MySpace є чудовим прикладом, він, між іншим, був перенесений на ASP.NET після роботи на серії різних платформ. Факти такі, проблеми з продуктивністю можуть прокрастися в веб-додатки при їх масштабуванні вгору, і в такому випадку виникає необхідність знайти реальну проблему, а також кращі стратегії її усунення. Найскладнішої із завдань, з якими при цьому доведеться зіткнутися, є створення набору показників, що охоплюють усі сторони продуктивності додатка. Зрозуміти, куди слід спрямувати зусилля, можна лише поглянувши на проблему в цілому.


Рівняння продуктивності


У вересні 2006 року Пітер Севчік (Peter Sevcik) і Ребекка Ветцель (Rebecca Wetzel) з компанії NetForecast опублікували документ, іменований “Field Guide to Application Delivery Systems” (“Польове керівництво по системам доставки додатків “). Основна увага в документі було приділено поліпшенню продуктивності додатків в глобальних мережах (wide area network – WAN), і в ньому було наведено рівняння з рис. 1. Це рівняння розглядає продуктивність глобальних мереж, але з кількома дрібними змінами його можна використовувати і для вимірювання продуктивності веб-додатків. Змінена рівняння показано на рис. 2, а його елементи пояснені на рис. 3.

 

Рис. 6 Distributed Database Architecture


Всі запити на запис даних відправляються баз даних записи, які розбиті на розділи і налаштовані на ефективну запис. Реплікація переміщує нові дані з баз записи на бази читання.


Створення таких спеціалізованих баз даних веде до затримки: у запису буде йти деякий час на розподіл по базах даних читання. Але якщо з затримкою вдасться розібратися, то потенціал масштабування величезний.



Нескінченна робота над масштабуванням


Поки додаток продовжує рости, продовжить рости і робота з його масштабуванню. Прийоми ASP.NET, ефективно працюють з 10 000 одночасно підключених користувачів, не так ефективні для 100 000, а для 1 мільйона користувачів правила змінюються знову. Звичайно, продуктивність може повністю залежати від програми, в деяких з тих, що ми бачили, проблеми з масштабуванням починалися при менше ніж тисячі користувачів!


Правило ефективного масштабування – сім разів відміряй, один раз відріж. Використовуйте тестування, щоб переконатися, що робота робиться там, де потрібно. Тестуйте свою роботу, щоб переконатися, що внесені поліпшення, а не просто зміни. Навіть наприкінці циклу розробки концентруйтеся на оптимізації для масштабування. Необхідно знати, де знаходяться найбільші повільні частини програми. Будемо сподіватися, вони досить швидкі для сьогоднішніх користувачів, дозволяючи працювати над тим, що буде потрібно користувачам завтра.


Річард Кемпбелл (Richard Campbell) є регіональним директором Майкрософт, володарем звання MVP по ASP.NET і одним з провідних ток-шоу з передачею звуку через Інтернет. NET Rocks для розробників для. NET (dotnetrocks.com). Він провів три роки консультуючись з компаніями з питань продуктивності і масштабування ASP.NET, а також є одним із засновників компанії Strangeloop Networks.

Kent Alstad є технічним директором компанії Strangeloop Networks (strangeloopnetworks.com) і основним автором або одним із співавторів всіх очікують реєстрації патентів Strangeloop. Перш ніж прийняти участь у створенні Strangeloop, він займався створенням численних високопродуктивних, високомасштабіруемих додатків ASP.NET і консультаціями по ним.

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


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

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

Ваш отзыв

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

*

*