Создание больших web-проектов
Автор: Олег Бунин
Источник: www.woweb.ru
У любого успешного web-проекта рано
или поздно возникает проблема роста. Существующие
программно-аппаратные ресурсы перестают справляться с растущей
нагрузкой. Универсальных рецептов, к сожалению не существует. В
каждом проекте хороший программист будет программировать по-разному.
Тем не менее, в этой статье я попробую дать несколько типичных
рекомендаций по созданию больших web-проектов. Такие проекты в
процессе создания и развития сталкиваются, как правило, с двумя
почти противоположными по способам решения проблемами - большими
скоростями и большими объемами данных.
Большие скорости
В качестве идеального примера сайта, для которого
жизненно важна скорость, можно взять баннерную сеть. Итак, несколько
приемов для ускорения работы баннерных сетей и других серверов,
критичных к скорости работы.
Создание модулей
Смысл этого приема - вкомпилировать
наиболее важные функции в сервер. Идея очень проста. Если мы
посмотрим на соотношение времени, которое тратится на различные
стадии выполнения запроса, то увидим интересную картину. Например,
при выполнении простейшего perl-скрипта последовательно происходит
следующее:
1) сервер Apache определяет
perl-скрипт для запуска, подготавливает и запускает его;
2)
запуск скрипта фактически начинается с запуска perl-интерпретатора
(это файл, размером около полумегабайта). Perl-интерпретатор,
запустившись, размещается на 2-х мегабайтах в памяти машины, и
только после этого приступает к работе с пользовательским
скриптом;
3) эта работа начинается с компиляции программы.
Компиляция программы - это, как правило, один из самых длительных
этапов обработки программы;
4) только после предварительной
компиляции (в байткод) скрипт начнет выполняться.
Статистика
удручает: время, которое тратится на запуск perl-интерпретатора и
компиляцию скрипта, как правило, на порядок больше времени, за
которое он выполняется.
На каждом сайте существуют узкие
места - программы, которые вызываются очень часто. Например,
баннерный движок. Как правило, на один просмотр страницы приходится
два-три баннера, а значит и вызова программы. Понятно, что если
избавиться от накладных расходов (пункты 2 и 3), работа сервера
значительно ускорится. Это можно сделать двумя похожими
способами.
Первый - написать модуль к Apache и вкомпилировать его
в сервер. Именно так в баннерной сети Фламинго-2 (http://www.f2.ru),
в создании которой я принимал участие, была реализована часть
системы, которая раздавала баннеры пользователям. Это был модуль,
написанный на языке C, который функционировал как часть сервера
Apache и поэтому работал очень быстро.
Второй способ -
использовать технологии предкомпиляции программ. Таких технологий
достаточно много. Например, для perl-скриптов это могут быть FastCGI
и mod_perl. Расскажу подробней о mod_perl. Это вкомпилированный
(опять же в виде модуля) в Apache perl-компилятор. Во-первых, даже
для простых скриптов (при надлежащей настройке) это исключает вторую
стадию выполнения. Но кроме этого mod_perl дает возможность писать
хэндлеры - обработчики определенных стадий выполнения запроса. Это
очень мощная технология, поэтому рассмотрим ее подробнее.
Можно,
например, написать хэндлер, который будет вызываться при запросе
определенного URL. Делается это так. В файл httpd.conf вы
прописываете следующие строки:
<Perl>
unshift(@INC, 'Путь к Вашему
модулю');
@PerlModule = qw(MyHandler);
%Location =
(
'/myhandler' => {
'PerlHandler' =>
'MyHandler::view',
'SetHandler' =>
'perl-script',
'PerlSendHeader' =>
'on'
},
);
</Perl>
Тем самым вы указываете Apache и
модулю mod_perl, что если пользователь запросит URL /myhandler, то
для его обработки должен запуститься модуль MyHandler, а в нем
процедура view. После изменения httpd.conf надо перезагрузить
Apache. Кстати, все указанные в конфигурационном модуле файлы будут
компилироваться при загрузке сервера, а не при первом запросе. Это в
несколько раз увеличит скорость работы сервера.
Модуль
MyHandler.pm может выглядеть, например, так:
package MyHandler;
use
strict;
# Процедура view
sub view {
print
"<HTML>\n<BODY>\nУра! Это отработал наш
хэндлер!</BODY>\n</HTML>\n";
}
1;
Механизм хэндлеров обладает мощными
возможностями. Фактически вы можете заменить любую стадию обработки
запросов. Рассмотрим для примера создание собственного механизма
проверки пароля:
package
MyAuthorization;
use strict;
# Обработчик, запрашивающий
пароль
sub handler {
my $r = shift;
return
AUTH_REQUIRED unless $r;
my (undef, $password) =
$r->get_basic_auth_pw;
my ($login) =
$r->connection->user;
return AUTH_REQUIRED unless
$password;
# Проверяем, все ли в порядке
# Проверка может
быть любой
# Можно свериться с базой данных, а мы будем считать,
что пароль должен быть
# равен логину, прочитанному задом
наперед.
my $rev_login = reverse($login);
# Проверка
пароля
if ($rev_login ne $passwd_sent)
{
return
AUTH_REQUIRED;
} else {
return OK;
}
};
1;
В файле настроек сервера httpd.conf
необходимо указать, что авторизовать пользователя мы будем сами:
%Location =
(
'/myhandler' => {
'PerlHandler' =>
'MyHandler::view',
'SetHandler' =>
'perl-script',
'PerlSendHeader' => 'on'
'require' =>
'valid-user',
'Limit' => {
'METHODS' => 'GET
POST'
},
'AuthType' => 'Basic',
'AuthName' =>
'PersonaUser',
'PerlAuthenHandler' => 'MyAuthorization
->handler()'
},
);
Теперь доступ к /myhandler защищен -
браузер выведет пользователю стандартное окно для ввода
пароля.
Более подробно с технологией mod_perl можно
познакомиться на сайте http://perl.apache.org/
Использование конвейеров
Старайтесь не производить обработку
данных в интерактивных скриптах. Записывайте их в лог-файлы, а затем
агрегируйте и обрабатывайте уже отдельным процессом. Например, ответ
пользователя в интерактивном голосовании может вызывать у вас
изменения в десятке различных параметров статистики (распределение
ответов, активность пользователей, общее число проголосовавших и так
далее). Не проводите их сразу. Вместо этого разбейте процедуру на
две части. Первая - непосредствен- но голосование, запись результата
и вывод ответной страницы пользователю. Вторая - обработка
голосования, изменение статистики и т.д.
Вообще надо
стараться минимизировать количество интерактивных операций. В
идеальном случае скрипт для учета голосования вообще ничего не
делает, кроме записи информации в лог-файл. А для обработки данных
из лог-файла можно запускать отдельный процесс-демон.
Для
примера рассмотрим механизм обработки статистики в баннерной сети
Фламинго-2. В ней был реализован 4-х ступенчатый конвейер:
1)
Информация о каждом запросе записывалась в полный лог. Это была
очень подробная информация и записывалась она без всякого сжатия, на
которое потратилось бы много времени. Размер этого лога очень велик
- одна запись в нем занимала 250 байт. Данные в этом логе не
хранились дольше нескольких часов.
2) С периодичностью раз в 10
минут запускалась программа, которая обрабатывала полный лог и в
компактном виде писала информацию в таблицы базы данных. На этой же
стадии учитывались показы, изменялись временные таблицы,
используемые для выдачи баннеров пользователю и для работы следующих
стадий.
3) Часовой демон, который строил почасовую статистику,
производил сложные географические расчеты и многое другое,
запускался в конвейере один раз в час. Он уже не имел доступа к
полному логу и использовал информацию исключительно из второй
стадии.
4) В задачи последней стадии входила дневная ротация
файлов, статистика, подведение балансов и рассылка почтовых
предупреждений. Эта стадия работала каждые сутки поздно ночью, когда
нагрузка на сервер была минимальной.
Как видите, механизм
достаточно сложный, и наладить его корректную работу было нелегко.
Чем больше стадий, тем больше проблем при их сопряжении друг с
другом. Тем не менее, такая система позволяла достаточно эффективно
распределять нагрузку и шустро работала на простом IDE-диске
(расчетная пропускная способность была около 2-3 миллионов обращений
в день при пиковой нагрузке 200 обращений в секунду). При этом
система вела большое количество статистики.
Итак, резюмируем:
для увеличения скорости работы программ, взаимодействующих с
пользователем, разбиваем их работу на части, причем интерактивная
часть должна содержать минимум расчетов и операций записи. Все
необходимые расчеты можно произвести позднее, в более благоприятное
с точки зрения нагрузки время и более эффективно.
Базы данных
Используйте хорошую базу данных. Какую
выбрать? Единого рецепта нет. Все зависит от решаемой задачи. Если
она достаточно простая и вам не требуется выполнять сложные
SQL-запросы (например, вложенные), то наилучшим решением будет,
пожалуй, база данных MySQL.
MySQL - один из самых простых
серверов БД. Но даже в этой простой базе есть свои способы
оптимизации для ускорения запросов. Например, не секрет, что INSERT
- одна из самых длительных операций (вычисление физического адреса
для вставки, вставка, решение проблемы фрагментации, изменение
индексов и служебных таблиц). Хороший прием для ускорения работы
скрипта, который вставляет данные в БД - замена операции INSERT
операцией INSERT DELAYED (отложенная вставка). Обновление данных
будет выполнено только тогда, когда это не приведет к замедлению
работы сервера.
Другой пример: если внимательно почитать
документацию MySQL, можно найти упоминание о таблицах, расположенных
в памяти (HEAP tables). Очевидно, что операции с такими таблицами
совершаются значительно быстрее. Heap-таблицы можно использовать для
решения некоторых задач.
Существует большое количество
параметров запуска сервера БД, оптимизирующих буферы сортировки,
вычислений, количество детей и другие параметры. Как правило, вам
заранее известно, что вы будете делать с базой, и для повышения
быстродействия можно задать соответствующие параметры. Например,
возьмем вполне реальную задачу: построение какого-нибудь каталога.
Ясно, что это будет одна большая таблица с большим количеством
индексов. Вы знаете, что будете использовать представления. Работа с
этой таблицей будет заключаться в запросах по индексу без
использования сортировки. Посмотрим, как можно настроить сервер БД
на выполнение такой задачи (пример из MySQL 3.23.25):
-
join_buffer_size - буфер для
создания представлений, по умолчанию равен 131072 байта;
-
key_buffer_size - буфер для работы с
ключами и индексами. Размер по умолчанию - 1048540;
-
sort_buffer - буфер для сортировки.
По умолчанию - 2097116 байт.
Скорее всего, при увеличении какого-то
буфера, скорость выполнения связанной с ним задачи увеличится.
Исходя из нашей задачи, мы увеличим буфер для работы с ключами
(скорость выборки значений из таблицы увеличится), уменьшим буфер
сортировки (уменьшится скорость сортировки) и буфер представлений
(уменьшится скорость работы с представлениями).
Строка запуска
демона MySQL будет выглядеть примерно так (конкретные значения
зависят от количества памяти в системе):
shell>safe_mysqld -O
key_buffer=8M -O sort_buffer=1M -O join_buffer=16K
Резюмируем.
При использовании базы данных работу скрипта можно значительно
ускорить правильной настройкой сервера БД. В руководстве базы данных
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-сайта в какой-то момент потребует слишком
много времени.
Объектно-ориентированное
программирование
О пользе объектно-ориентированного
подхода я уже рассказывал . Повторю вкратце. Каждый, кто хоть раз
пробовал создавать динамические сайты, знает, что во многом это -
очень однообразная задача. Гостевая книга, конференция, форма для
отправления комментариев, подписка, регистрация. Как правило, эти
скрипты слабо интегрированы и, в лучшем случае, используют общую
библиотеку с константами и общими процедурами.
Однако если
перечислить сущности, с которыми имеют дело вышеперечисленные
скрипты, мы получим очень интересные результаты:
-
Сущность "пользователь". Имеет свое
имя, фамилию, ник, пароль, электронный адрес: Используется
практически во всех скриптах в разных ипостасях.
-
Сущность "сообщение". Вы можете
возразить, что сообщения везде разные. Ничего подобного!
Различаются формы представления сообщений, а данные, структура
полей и методы обработки - одни. Автор, заголовок, тело - и так во
всех проектах.
Вот фактически и все сущности, с
которыми оперирует большинство скриптов на сайте. Гостевая книга
(она, кстати, сама может быть объектом в более сложных проектах)
представляет собой цепочку объектов класса "сообщение". Форум или
конференция - те же сообщения, организованные иерархически. Отправка
письма владельцу сайта - сообщение. Рассылка анонсов - перебор
объектов класса "пользователь" и отправка каждому объекта класса
"сообщение".
Было бы эффективно описать все эти объекты в одном
месте, а потом строить из них, как из кирпичиков, программы и
скрипты, просто вставляя вызовы объектов в код. К тому же, единое
пространство сообщений, пользователей и других объектов значительно
расширяет поле для творчества.
В этом и есть сущность объектного
подхода. Вы создаете множество объектов - кирпичиков будущих
программ - и из них строите свои сайты. Кроме того, вы можете
использовать такие мощные методы ООП как наследование и полиформизм,
без которых уже немыслимо построение крупных проектов.
Шаблонирование
Об этом я тоже расскажу вкратце;
возможно этому будет посвящена статья в одном из следующих номеров
"Программиста". Вернемся к системе Фламинго. Как был организован
интерфейс этой баннерной сети? 400 видов статистики соответствуют
400 страницам? Нет. Один скрипт-шаблонизатор, которому передаются
параметры - номер статистики и другие данные: даты, ограничения и
т.д.
По уникальному номеру статистики скрипт считывал описание,
которое состояло из имени файла с псевдо-html и имен файлов с
SQL-запросами. Файл с описанием выглядел так:
2:data/html/2.htx,data/queries/info.sql
9:data/html/9.htx,data/queries/ban-list-one.sql,data/queries/get-banners-list.sql
12:data/html/12.htx,data/queries/ban-getinfo.sql
38:data/html/38.htx,data/queries/acc-hosts-hits.sql
44:data/html/44.htx,data/queries/acc-getsites-today.sql
Общая схема очень проста - выполнить
все SQL-запросы и вставить результаты в псевдо-html, получив таким
образом полноценную страничку, и выдать ее пользователю. Например,
для вывода статистики с номером 2 (информация об аккаунте),
требовалось выполнить SQL-запрос data/queries/info.sql, результаты
вставить в data/html/2.htx. Результат вывести на экран.
А вот
как обстояло дело подробнее. Первая задача - формирование
SQL-запроса. В него нужно вставить идентификатор пользователя и
другие параметры, которые переданы скрипту. Типичный пример
SQL-запроса (data/queries/info.sql):
select
AccountName,
OwnerName,
OwnerEmail,
MainSite,
SiteName
from
Accounts
where
AccountId
= <--AccountId-->
При разборе такого запроса значение
параметра вставлялось на место строки <--ИмяПараметра-->.
Существовали и специальные параметры, например -
<--UserName--> - имя пользователя и <--AccountId--> -
вычисленный по имени идентификатор аккаунта.
Результат
выполнения полученного запроса заносился в html следующим образом.
Каждое полученное из базы данных значение получало "имя", с помощью
которого обозначалось его местоположение в html-шаблоне. Имя было
составным. Первая часть - порядковый номер SQL-запроса, вторая часть
- индекс значения в массиве результатов.
Допустим, выполнялся
SQL-запрос с порядковым номером 1 (для примера рассмотрим запрос
data/queries/info.sql). Запрос возвращал массив значений.
Соответственно, значение AccountName, возвращенное базой данных,
имело порядковый номер 0 в этом массиве. В html-шаблоне место, куда
необходимо было вставить AccountName обозначалось как
<--1.1-->.
Кусочек HTML-шаблона data/html/2.htx
из нашего примера:
<TABLE BORDER=0
WIDTH=460>
<TR>
<TD WIDTH="50%">
<FONT
SIZE="-1">
Имя, фамилия
ответственного:
</FONT>
</TD><TD>
<INPUT
type="text" name="OwnerName" size=33
value="<--1.1-->">
</TD>
</TR>
<TR>
<TD>
<FONT
SIZE="-1">
Электронный
адрес:
</TD><TD>
<INPUT type="text"
name="OwnerEmail" size=33
value="<--1.2-->">
</TD>
</TR>
Несмотря на кажущуюся сложность схемы,
она имеет ряд преимуществ. С ее помощью мы смогли за короткое время
построить систему с более чем 400 видами различных статистик.
Впоследствии для добавления новой статистики надо было только
написать SQL-запросы, нарисовать HTML-шаблон и изменить конфигурацию
скрипта-шаблонизатора. Новая страница статистики появлялась в
системе автоматически.
Заключение
Я хотел бы еще раз повторить: нет
решений на все случаи жизни. Каждый раз, в каждом проекте вам
придется придумывать собственные методы оптимизации быстродействия и
удобства работы. Я надеюсь, что приемы, о которых я рассказал,
пригодятся вам. Если у вас возникнут какие-нибудь вопросы или
уточнения, я готов обсудить их с вами - vbob@aha.ru
|
