Разработка информационного web-сайта на основе системы «1С-Битрикс: Управление сайтом»

7.3.2. Настройка Subversion для работы с web-приложением

В состав дистрибутива GNU/Linux, установленного на компьютере web-приложения, Subversion входит и установлен. Для настройки системы Subversion, таким образом, необходимо выполнить следующую последовательность действий:

1. Создание и настройка репозитория;
2. Версионирование файлов и папок web-приложения;
3. Создание рабочей копии на локальном компьютере;

 

 

Создание и настройка репозитория.

Для того чтобы создать и настроить репозиторий, необходимо в командной строке операционной системы выполнить команду svnadmin create <имя_репозитория>. В нашем случае репозиторий будет носить имя metagames. Соответственно, команда будет иметь вид:

[root@v8733 ~]# svnadmin create /home/svn/metagames

Все хранилища расположены в директории /home/svn.

Далее следует настроить доступ к репозиторию, указав логин и пароль доступа к репозиторию, название репозитория и права доступа разных групп пользователей к репозиторию. Для этого нужно править файл svnserve.conf, находящийся в файле /home/svn/metagames:

anon-access=none

auth-access=write

password-db=passwd

realm=metagames

В данном файле мы запретили доступ к репозиторию всем пользователям, кроме авторизованных, указали имя репозитория (metagames) и указали имя файла, содержащего логин и пароль доступа к репозиторию (passwd).

После внесения изменений необходимо перезапустить процесс системы Subversion, выполнив последовательно команды killall и svnserve.

[bitrix@v8733 ~]# killall svnserve;

[bitrix@v8733 ~]# svnserve –d –r /home/svn

Важно отметить, что процесс web-сервера Apache (httpd) на компьютере web-приложения запущен от имени пользователя с именем bitrix. Соответственно, владельцем файлов web-приложения является указанный выше пользователь. Поэтому запуск процесса системы Subversion svnserve следует выполнить от имени пользователя с именем bitrix, чтобы обеспечить сохранность настроек доступа и владельца изменяемых файлов.

Стандартная структура файлов верхнего уровня репозитория содержит следующую структуру:

branches

trunk

tags

Для того чтобы зафиксировать такую файловую структуру в репозитории, необходимо создать какую – нибудь папку в файловой структуре компьютера (например, init) web-приложения, выполнить команду checkout

svn checkout svn://metagames.ru/metagames/ init

, создать в данной папке указанные выше подпапки, выполнить для каждой из созданных подпапок команду add

svn add init/branches

….

и выполнить команду commit

svn commit init –m “Start doings”.

После этого в репозитории будет создана и версионирована требуемая структура.

 

Версионирование файлов и папок web-приложения.

Для того, чтобы версионировать файлы и папки web-приложения, нужно заранее определиться, какие именно файлы и папки стоит заносить в репозиторий, какие нет. После этого для выбранных папок следует выполнить команду checkout, например:

svn checkout svn://metagames.ru/metagames/trunk /home/bitrix/www/index/

Далее следует выполнить команду добавления требуемых файлов и подпапок выбранной папки и выполнить команду add.

svn add home/bitrix/www/index/all/

svn add home/bitrix/www/index/index.php

В конце следует зафиксировать изменения в репозитории, выполнив команду commit

svn commit home/bitrix/www/index –m “Сценарии всех платформ“.

Таким образом, выполнив данные процедуры для всех папок и файлов web-приложения, можно сформировать структуру репозитория.

Создание рабочей копии на локальном компьютере.

Теперь, когда репозиторий на компьютере web-приложения создан, можно выполнить снимок репозитория и создать рабочую копию репозитория на удаленном компьютере. Для этого можно воспользоваться программой – клиентом системы Subversion Tortoise SVN. Данная программа позволяет работать с репозиторием, вносить изменения в файлы и фиксировать их. В данной программе в графическом режиме доступны команды update, add, commit и т.д. В процессе разработки web-приложения на локальном копьютере была развернута копия web-приложения, затем для корневой папки с помощью команды Tortoise SVN checkout было выполнено версионирование файлов локального компьютера. Дальнейшие изменения файлов web-приложения проходили и проходят по следующему сценарию:

1. Изменение файла, например, /home/bitrix/index.php на локальном компьютере;
2. Выполнение фиксации изменений данного файла в репозитории с помощью команды Tortoise SVN commit;
3. Выполнение команды svn update для файла самого web-приложения в командной строке операционной системы, управляющей web-приложением на удаленном компьютере;

Данная технология управления версиями была использована при разработке web-приложения и используется в данный момент для поддержания работы web-приложения и обеспечения возможности работы над web-приложением нескольких разработчиков. Также стоит отметить важное для разработки свойство сохранения истории разработки в виде версий, которое позволяет следить за процессом разработки и делать откаты изменений в сценариях web-приложения, если разработчиками допущены какие – либо ошибки. Плюсом является то, что для доступа к файловой структуре web-приложения более не требуется доступов по протоколам FTP и HTTP, весь процесс разработки проходит на локальном компьютере, что позволяет максимально отладить сценарии перед обновлением репозитория и файлов web-приложения. Минусами использования системы управления версиями при разработке web-приложения является то, что от разработчиков в данном случае требуется наличие знаний по работе с данной системой. Также следует отметить то, что приходится разворачивать локальную копию web-приложения на компьютере разработчика, но наличие таких пакетов разработки, как «Джентльменский набор Web-разработчика», заметно упрощает данный процесс.

 

8. Нагрузочное тестирование

8.1. Общие сведения

Нагрузочное тестирование применяется для того, чтобы определить, насколько производительно разработанное web-приложение и насколько оно готово к обслуживанию большого количества клиентов. Проведение нагрузочного тестирования, которое еще называют «стресс-тест», позволяет не только определить среднее значение пользователей, которые могут быть обслужены web-приложением без существенных задержек, но и определить «узкие места» web-приложения, т.е. ошибки в работе сценариев web-приложения, большие расходы ресурсов при запросах к СУБД, неверные конфигурации web-сервера и другие ошибки, которые могут вызвать замедление работы web-приложения.

8.2. Техника проведения  нагрузочного тестирования

Для того чтобы провести нагрузочное тестирование, необходимо выполнить следующие действия:

1. Имитировать нагрузку на компьютер web-приложения;
2. Во время имитации нагрузки снимать показатели, важные для анализа результатов теста;
3. При необходимости повторить указанные выше пункты с большими значениями нагрузки;

Имитация нагрузки

Требования к способам имитации нагрузки:

• должна быть возможность указать время имитации;
• должна быть возможность указать количество одновременных запросов;
• должна быть возможность указать файл со списком адресов страниц web-приложения, на сценарии которых должна осуществляться нагрузка, должна быть возможность примерной имитации поведения пользователя сети Internet (случайные переходы и т.д.);

Наиболее подходящим средством является программа Siege [12], которая реализует указанные выше требования. Данная программа должна быть установлена на сторонний компьютер с операционной системой GNU/Linux, в нашем случае – GNU/Linux Ubuntu 10.4. После установки программу можно запустить из командной строки ОС.

Получение показателей нагрузки.

Для того чтобы получать показатели производительности, в системе «1С – Битрикс: Управление сайтом» предусмотрен модуль «Производительность». Данный модуль предоставляет возможность для просмотра результатов нагрузки на web-приложение, таких как время генерации страницы, количество и время запросов к СУБД в сценариях компонентов, расположенных на странице web-приложения и средние показатели нагрузки на компьютер web-приложения при обращении пользователя к той или иной странице. Для того чтобы осуществить анализ нагрузки на компьютер web-приложения, в модуле «Производительность» необходимо запустить временной сценарий, который принято в системе называть «панелью производительности».

 

Рисунок 9 – Данные, предоставляемые модулем “Производительность”

 

Таким образом, техника нагрузочного тестирования, выбранная мной, заключается в сколь возможно одновременном запуске программы Siege на стороннем компьютере и панели производительности на компьютере web-приложения и последующей оценки данных, предоставляемых панелью производительности после завершения имитации нагрузки на компьютер web-приложения.

 

 

 

Проведение нагрузочного тестирования.

Для того, чтобы начать имитацию нагрузки на компьютер web-приложения, необходимо запустить в командной строке ОС стороннего компьютера процесс программы Siege:

[root@v8733 ~]# siege -c 50 -d 1 -t300S -f /home/dima/access_log.log

-c 50 – количество одновременных запросов к компьютеру web-приложения, t300S – время имитации, -d 1 – интервал между запросами (от 0 до 1 секунды), /home/dima/access_log.log – файл с адресами, на которые необходимо осуществлять запросы. Наиболее простым способом получения файла access_log.log является написание специальной функции, которая будет вызываться каждый раз при загрузке какой – либо страницы web-приложения и фиксировать в определенном файле уникальные адреса страниц. Далее следует открывать страницы web-приложения, чтобы файл автоматически пополнялся адресами. Примерное количество адресов, достаточных для выполнения имитации, будем считать 150 адресов. Это число больше, чем физическое число страниц web-приложения, но в списке адресов имеются адреса запросов к страницам с разными параметрами GET и POST.

Для реализации сбора адресов была написана функция:

void write_access_log(string filepath)

, где filepath – имя файла, в который  будут записаны адреса посещаемых пользователями страниц. Исходный код данной функции представлен в приложении Д.

После запуска процесса Siege следует сразу же запустить панель производительности. В течение некоторого времени будет осуществляться анализ и фиксация данных нагрузки и в конце будет выведен результат в виде таблицы, по которому можно будет судить о способности web-приложения выдерживать нагрузки.

8.3. Оценка результатов  тестирования

Для проведения первого теста было выбрано число одновременных пользователей, равное 100 (с=100) и время имитации, равное 300 секунд (t=300S).

[root@v8733 ~]# siege -c 100 -d 1 -t300S –i -f /home/dima/access_log.log

При проведении данного теста были получены следующие результаты:

 

Таблица 2 – результаты теста 1; с=100, t=300S

Адрес страницы	Нагрузка, %	Среднее время формирования страницы, сек
/pc/index.php	49.43	6.0035
/index/new/all/index.php	18.92	10.6723
/pc/new/index.php	9.87	3.7513
/detail/index.php	5.99	1.7449
/index/top/index.php	1.39	3.0484
/xbox_360/index.php	1.20	2.0960
/about/index.php	0.80	1.9985
/advertisement/index.php	0.74	1.8442
/contacts/index.php	0.63	1.5661
/pc/upcoming/index.php	0.57	1.6750
/pc/top/index.php	5.62	0.4352
/search/index.php	2.92	0.7424
/index/new/index.php	1.94	2.6039

 

Данные результаты позволяют судить о том, что в сценариях компонентов имеются серьезные недочёты, из-за которых используется большое количество ресурсов компьютера и замедляется процесс формирования страницы и отправки её пользователю. Наиболее серьёзному анализу следует подвергнуть компоненты страниц /index/new/all/index.php. Как следует из диаграммы, размещенной на рисунке 7 (раздел 6), на данной странице находится компонент games.calendar. В процессе реализации логики работы компонента для получения свойств элементов информационного блока, указанного в настройках компонента, используется метод _CIBElement::GetProperties(), который выбирает все свойства элемента, следствием чего стало большое число запросов к web-приложению и формирование большого файла кэша (свыше 1 Мб). Данный метод был использован для универсальности работы компонента: в одном из шаблонов компонента можно было бы получить значение любого из свойств без дополнительных действий. Но платой за универсальность является замедление работы компонента. После совещания с заказчиком было принято решение изменить сценарий работы компонента, устранив указанные выше недостатки и тем самым понизив универсальность компонента, но значительно повысив производительность работы компонента.

После внесения изменений для тех же показателей был проведен второй тест, который дал результаты, указанные в таблице 3.

 

Таблица 3  – результаты теста 2. с=100, t=300S

Адрес страницы	Нагрузка, %	Среднее время формирования страницы, сек
/pc/index.php	29.72	0.9559
/index/new/all/index.php	22.06	0.6110
/pc/new/index.php	4.13	0.7122
/detail/index.php	5.37	0.4817
/index/top/index.php	2.11	0.4624
/xbox_360/index.php	1.51	0.6463
/about/index.php	0.48	0.2360
/advertisement/index.php	0.72	0.5875
/contacts/index.php	0.48	0.4291
/pc/upcoming/index.php	1.03	0.9263
/pc/top/index.php	3.31	1.0613
/search/index.php	9.08	1.9390
/index/new/index.php	3.43	0.4970