студент групи ПЗ-07м Гриб В. О.

Державний ВНЗ «Національний гірничий університет», Україна

Вплив характеристик СУБД веб –додатку на продуктивність веб-серверу

Веб-додаток — розподілений додаток, в якому клієнтом виступає браузер, а сервером — веб-сервер. Логіка веб-додатку зосереджується на сервері, а функція браузера полягає в основному у відображенні інформації, завантаженої по мережі з сервера, і передачі назад даних користувача. Як бачимо, внаслідок того, що веб-додатки використовують ресурси веб-серверу, їх характеристики мають значний вплив на продуктивність. З метою попередження перевантаження серверу потрібно приділяти підвищену увагу використанню кешування, роботі з БД, передачі даних по мережі, оптимізації коду програми.

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

Одним з найбільш часто виникаючих питань, є наступне: чи варто в принципі використовувати СУБД для зберігання тих чи інших даних або обмежитися зберіганням даних у файли? Як правило, основною причиною вибору між цими підходами є те, як передбачається працювати з даними. Якщо це часто-обновлюваний контент, або взаємодія з даними припускає складну логіку (наприклад, використання багатопараметричних виборок чи необхідність забезпечення багатокористувацької підтримки), має сенс використовувати готову СУБД. В іншому випадку, доведеться самостійно реалізовувати безліч функцій, які виконувалися б засобами БД, і витрачати на це додатковий час.

Безпосередньо файлову систему розумно використовувати для зберігання статичного контенту. Хороший тому приклад - графічні файли, які більшість CMS зберігають окремо від текстів статей. Самі ж статті при цьому розміщуються в таблицях БД, де їх легше редагувати та індексувати – це обгрунтований вибір між двома крайнощами.

Хибною думкою є те, що для підвищення продуктивності при розробці баз даних достатньо проіндексувати всі можливі стовпці. Ці дії не тільки марні, але й загрожують зниженням продуктивності в кілька разів. Суть проблеми вибору індексів в тому, що SQL-сервер повинен змінювати їх при будь-яких "реформах" в таблицях (INSERT, UPDATE, DELETE). Якщо індексів один або два, великих втрат продуктивності не буде, але якщо їх набагато більше, SQL-сервер піддається великим навантаженням при роботі з таблицями.

Один і той же результат може бути отриманий СУБД різними способами, які істотно відрізняються як за витратами ресурсів, так і за часом виконання. Оптимізовані запити значно покращують показник продуктивності. Після оптимізації запиту індекс може стати невживаним. Іноді SQL-серверу потрібно менше часу на перебір таблиці, ніж на використання індексу. Такі індекси служать баластом і повинні бути вилучені. Їх можна відловити аналізатором SQL-запитів, який дасть повну картину обробки запитів.

В ідеалі весь код Transact-SQL, використовуваний в додатках, повинен перебувати в збережених процедурах, а не запускатися у вигляді динамічного SQL або скриптів. Це зменшує мережний трафік і прискорює виконання самого коду Transact-SQL, так як код в збережених процедурах являється перекомпільованим. Коли процедура, що зберігається виконується в перший раз (і в неї не визначена опція WITH RECOMPILE), вона оптимізується, для неї створюється план виконання запиту, який кешується SQL-сервером. Якщо та ж сама процедура, що зберігається викликається знову, вона буде використовувати кеш-план виконання запиту, що заощадить час і збільшить продуктивність. Але якщо запит динамічний (змінюється від одного виконання збереженої процедури до іншого), оптимізації не буде, а продуктивність тільки постраждає. Якщо відомо, що запит буде мінятися кожен раз при виконанні процедури, потрібно додати опцію WITH RECOMPILE, яка змусить перекомпілювати збережену процедуру заново і оптимізувати запит.

Інша неприємна особливість, з якою можна зіткнутися, - блокування (deadLock). Це той випадок, коли два процеси намагаються заблокувати два об'єкти, причому кожен процес намагається заблокувати об'єкт, який належить іншому процесу. У цьому випадку SQL-сервер перериває один з процесів, відкатує його транзакцію, тим самим дозволяючи другого процесу продовжити роботу. Цього можна уникнути, якщо отримувати доступ до об'єктів в одному і тому ж порядку і не допускати користувача введення під час транзакцій. Тобто отримати всі необхідні дані до початку транзакції.

Причиною падіння продуктивності можуть стати і тригери. При їх використанні треба дотримуватися простих правил, а саме:

· чим менше код тригера, тим краще і тим швидше виконуються операції;

· не використовувати тригери для задач, які можуть бути реалізовані іншими, більш ефективними способами;

· проводити перевірку помилок робити до спрацьовування тригера. Так споживається менше ресурсів, ніж при відкаті транзакцій тригером.

Висновок

Таким чином в результаті дослідження ми дійшли висновку, що одним з основних факторів, які впливають продуктивність веб-серверу, є структура СУБД. Для забезпечення ефективної роботи з СУБД необхідно, щоб таблиці були коректно проіндексовані і використовувалися оптимізовані запити.

Література

1. Поль Дюбуа «Применение MySQL и Perl в Web-приложениях», видавництво Вільямс, 2002р. 480 стр.

2. Берон Шварц «MySQL. Оптимизация производительности», видавництво Символ-Плюс, 2010р., 832стр.

3. Деніел Менаске, Віргіліо Алмейда «Производительность Web-служб. Анализ, оценка и планирование», видавництво ДиаСофтЮП, 2003р., 480стр.

4. Нільсен, Пол. «Microsoft SQL Server 2005. Библия пользователя.», Пер. с англ. — М. : ООО “Вільямс”, 2008р. — 1232 стр.