Створення великих web-проектів, Perl
У будь-якого успішного web-проекту рано чи пізно виникає проблема зростання. Існуючі програмно-апаратні ресурси перестають справлятися з зростаючим навантаженням. Універсальних рецептів, на жаль, не існує. У кожному проекті хороший програміст програмуватиме по-різному. Тим не менш, у цій статті я спробую дати кілька типових рекомендацій щодо створення великих веб-проектів. Такі проекти у процесі створення та розвитку стикаються, як правило, із двома майже протилежними за способами вирішення проблемами — великими швидкостями та великими обсягами даних.
Великі швидкості
Як ідеальний приклад сайту, для якого життєво важлива швидкість, можна взяти банерну мережу. Отже, кілька прийомів прискорення роботи банерних мереж та інших серверів, критичних до швидкості роботи.
Створення модулів
Сенс цього прийому - вкомпілювати найважливіші функції на сервер. Ідея дуже проста. Якщо ми подивимося на співвідношення часу, що витрачається різні стадії виконання запиту, то побачимо цікаву картину. Наприклад, при виконанні найпростішого perl-скрипту послідовно відбувається таке:
1) сервер Apache визначає perl-скрипт для запуску, готує та запускає його; 2) запуск скрипта фактично починається з запуску perl-інтерпретатора (це файл, розміром близько півмегабайта). Perl-інтерпретатор, запустившись, розміщується на 2-х мегабайтах у пам'яті машини, і тільки після цього приступає до роботи з скриптом користувача; 3) ця робота починається з компіляції програми. Компіляція програми - це, як правило, один із найтриваліших етапів обробки програми; 4) тільки після попередньої компіляції (байткод) скрипт почне виконуватися.
Тим самим ви вказуєте Apache і модулю mod_perl, що й користувач запросить URL /myhandler, то його обробки повинен запуститися модуль MyHandler, а ньому процедура view. Після зміни httpd.conf необхідно перезавантажити Apache. До речі, всі вказані в модулі конфігурації файли будуть компілюватися при завантаженні сервера, а не при першому запиті. Це в кілька разів збільшить швидкість сервера. Модуль MyHandler.pm може виглядати, наприклад, так:
Механізм хендлерів має потужні можливості. Фактично можна замінити будь-яку стадію обробки запитів. Розглянемо для прикладу створення власного механізму перевірки пароля:
Тепер доступ до /myhandler захищений – браузер виведе користувачеві стандартне вікно для введення пароля. Докладніше з технологією mod_perl можна познайомитися на сайті http://perl.apache.org/
Використання конвеєрів
Намагайтеся не робити обробку даних в інтерактивних скриптах. Записуйте їх у лог-файли, а потім агрегуйте та обробляйте вже окремим процесом. Наприклад, відповідь користувача в інтерактивному голосуванні може викликати зміни в десятці різних параметрів статистики (розподіл відповідей, активність користувачів, загальна кількість тих, хто проголосував і так далі). Не проводьте їх одразу. Натомість розбийте процедуру на дві частини. Перша — безпосереднє голосування, запис результату та виведення сторінки у відповідь користувачу. Друга – обробка голосування, зміна статистики тощо. Взагалі треба намагатися мінімізувати кількість інтерактивних операцій. В ідеальному випадку скрипт для обліку голосування взагалі нічого не робить, окрім запису інформації до лог-файлу. А для обробки даних із лог-файлу можна запускати окремий процес-демон. Для прикладу розглянемомеханізм обробки статистики у банерній мережі Фламінго-2. У ній був реалізований 4-ступінчастий конвеєр:
Як бачите, механізм досить складний і налагодити його коректну роботу було нелегко. Чим більше стадій, тим більше проблем при їх поєднанні один з одним. Тим не менш, така система дозволяла досить ефективно розподіляти навантаження і швидко працювала на простому IDE-диску (розрахункова пропускна здатність була близько 2-3 мільйонів звернень на день при піковому навантаженні 200 звернень на секунду). При цьому система вела велику кількість статистики.
Отже, резюмуємо: для збільшення швидкості роботи програм, що взаємодіють з користувачем, розбиваємо їх роботу на частини, причому інтерактивна частина повинна містити мінімум розрахунків та операцій запису. Усі необхідні розрахунки можна зробити пізніше, у більш сприятливий з погляду навантаження час і ефективніше.
Бази даних
- join_buffer_size - буфер для створення уявлень, за умовчанням дорівнює 131072 байта;
- key_buffer_size - буфер для роботи з ключами та індексами. Розмір за замовчуванням – 1048540;
- sort_buffer - буфер для сортування. За замовчуванням - 2097116 байт.
Швидше за все, при збільшенні якогось буфера швидкість виконання пов'язаного з ним завдання збільшиться. Виходячи з нашого завдання, ми збільшимо буфер для роботи з ключами (швидкість вибірки значень таблиці збільшиться), зменшимо буфер сортування (зменшиться швидкість сортування) та буфер уявлень (зменшиться швидкість роботи з уявленнями). Рядок запуску демона MySQL буде виглядати приблизно так (конкретні значення залежать від кількості пам'яті в системі):
Резюмуємо: під час використання бази даних роботу скрипту можна значно прискорити правильним налаштуваннямсервера БД. У посібнику бази даних MySQL є спеціальний розділ, присвячений оптимізації. За більш детальною інформацією можна звернутися на сайти: Розробники MySQL - http://www.mysql.com Розробники PostgreSQL - http://www.PostgreSQL.org/ Оптимізація MySQL - http:// www.mysql.cz/information/presentations/presentation-oscon2000-20000719/index.html та http://support.ultrahost.ru/mysql_opt.php
Великі обсяги
Ще одна проблема великих сайтів – великий обсяг інформації. Якщо не застосовувати жодних хитрощів, то підтримка простого html-сайту в якийсь момент вимагатиме занадто багато часу.
Об'єктно-орієнтоване програмування
Однак якщо перерахувати сутності, з якими мають справу перераховані вище скрипти, ми отримаємо дуже цікаві результати:
Шаблонування
Шматок HTML-шаблону data/html/2.htx з нашого прикладу:
Незважаючи на складність схеми, що здається, вона має ряд переваг. З її допомогою ми змогли за короткий час побудувати систему з більш ніж 400 різними статистиками. Згодом для додавання нової статистики треба було лише написати SQL-запити, намалювати HTML-шаблон та змінити конфігурацію скрипта-шаблонізатора. Нова сторінка статистики з'являлася автоматично.
Висновок
Я хотів би ще раз повторити: нема рішень на всі випадки життя. Щоразу, у кожному проекті вам доведеться вигадувати власні методи оптимізації швидкодії та зручності роботи. Я сподіваюся, що прийоми, про які я розповів, стануть вам у нагоді.