Тестирование выгрузки 200 000 товаров на сайт из 1С

В одном из проектов перед нами стояла задача выгрузки из 1С на сайт большого количества товаров с периодичностью 2 раза в день. Хотим поделиться опытом, полученным при проведении нагрузочного тестирования проекта.

Мы изучили несколько статей на Хабре:
http://habrahabr.ru/post/77593/ ^[1]
http://habrahabr.ru/company/ontico/blog/95060/ ^[2]
http://habrahabr.ru/post/113914/ ^[3]

Сначала предстояло решить три вопроса:

Что тестировать?
Как проводить мониторинг полученных результатов?
Как тестировать?

Начнем по порядку.

Что тестировать?

Наш стенд состоит из трёх основных элементов:

Сервера 1С (Intel@Core i3-2125, 8 GB RAM)
модуля PHP для обработки данных, пришедших из платформы 1С на сайт (Back-end REST Service)
веб-интерфейса сайта

Основной функционал системы заключается в обмене xml-сообщениями между 1С и модулем обработки данных (REST), находящемся на сервере приложений. Модуль обработки получает данные из 1С и записывает их в базу данных. Веб–интерфейс сайта работает с базой данных.

Как проводить мониторинг полученных результатов?

В качестве средства мониторинга был выбран Zabbix ^[4] — наиболее доступная система, которая отличается простотой в установке и использовании. Zabbix позволил нам не только наблюдать за процессом тестирования в режиме real-time, но и вести статистику, исходя из которой мы можем прогнозировать нагрузку и рассчитать значение показателей RPO ^[5] (Recovery Point Objective) и RTO ^[6] (Recovery Time Objective), а также доступность системы (Agreed Service Time ^[7]).

Тестирование выгрузки 200 000 товаров на сайт из 1С

Как тестировать?

Поскольку в системе можно выделить две основные части, постараемся выявить возможные изъяны именно в них. Первая — это взаимодействие шлюза 1С и обработчика XML в вебе. Вторая — это взаимодействие пользователя с базой данных через веб-интерфейс.
Итак, приступим:

Тестирование обмена 1С-Сайт
Для начала примем во внимание то, что самое “узкое” место обмена можно будет обнаружить при первой выгрузке всех необходимых для работы системы объектов из базы 1С в веб. Так как под рукой не было базы 1С с достаточным количеством объектов, мы написали скрипт для создания расширенного списка номенклатуры и контрагентов в 1С с сохранением всех необходимых связей. В результате работы скрипта в базе появилось 200 тыс. объектов.

Выгружаемые объекты имели структуру следующего вида:
```
<Номенклатура> 
<ИД>8729</ИД> 
<ВремяИзменения>2012-12-17T10:46:15</ВремяИзменения> <Ссылка>c9358c28-f33f-11e1-b5e6-00155d002500</Ссылка> <ПометкаУдаления>0</ПометкаУдаления> 
<Артикул/> 
<Наименование>Лопата</Наименование> <Родитель>e8a71fc3-55bc-11d9-848a-00112f43529a</Родитель> <ЭтоГруппа>0</ЭтоГруппа> <НаименованиеПолное>Лопата</НаименованиеПолное>
<Комментарий/> 
<Каталог>e61d7694-cffa-11e1-99dc-0030678e0763</Каталог> </Номенклатура>
```
Всего подобных структур около 32.

Итак, настроив обмен и проверив всё ещё раз, начинаем полную выгрузку из 1С в веб и смотрим графики.

Результаты: Первоначальная выгрузка товаров продолжалась в около 9 часов. “Узким” местом, при выгрузке из 1С большого количества данных, является производительность шлюза 1С, которая напрямую связана с мощностями сервера и ограничениями платформы. Также выявили проблему обмена, с которой предстоит разобраться в кратчайшие сроки — отсутствие выгрузки с 23:00 до 02:00.

Следующим этапом тестирования будет создание идеального стенда с неограниченными мощностями сервера 1С и «широким» каналом связи. Тестирование показало, что на данном этапе нужно уделить отдельное внимание оптимизации кода 1С и протестировать двусторонний обмен в разных режимах нагрузки. В ближайшем будущем намечено комплексное исследование этого вопроса, по итогам которого будет написана 2-я статья.
Тестирование веб-интерфейса
Цель данного тестирования — подсчет количества одновременно работающих пользователей, которых может эффективно обслуживать система.
Для начала определимся с понятием “эффективно”. Будем считать, что “эффективность” достигается в случае, когда время загрузки произвольной страницы составляет не более одной секунды.
Время ping до нашего тестового сервера не превышает 55ms.

Для нагрузочного тестирования решили использовать такие системы как Apache Benchmark и Tsung.

Apache Benchmark
100 пользователей, 10 из которых одновременно осуществляют запрос, используя поисковую систему сайта.
```
ab -n 100 -c 10 -u putdata.txt  -e search.csv  Адрес_сайта
```
Putdata.txt – содержит слова, которые вводятся в поисковую форму. Результат записывает search.csv файл.

Результат: 98% запросов обработались в пределах 1 секунды.

Tsung
1. Создадим сценарий, используя утилиту tsung-record. Tsung-record записывает действия клиента через прокси-сервер — Tsung Proxy. Остаётся прописать адрес прокси-сервера в браузере -127.0.0.1 и порт 8090, который будет слушать запросы.
  
  И в терминале выполним команду tsung-record–star
2. Открываем браузер и выполняем обычные действия пользователя:
  ● Просматриваем категории товаров;
  ● Осуществляем заказ товаров;
  ● Пользуемся поиском;
  ● Добавляем новый товар в заказ;
  
  Завершив работу в браузере, останавливаем tsung-recorder командой stop.
3. В результате был создан файл, содержащий в себе Get запросы:
```
<session name='rec20121127-1403' probability='100'  type='ts_http'>
<request><http url='http://сайт/' version='1.0' method='GET'></http></request>
<request><http url='/thumbs/92_width_80.jpg' version='1.0' method='GET'></http></request>
<request><http url='/thumbs/93_width_80.jpg' version='1.0' method='GET'></http></request>
<request><http url='/thumbs/97_width_80.jpg' version='1.0' method='GET'></http></request>
<request><http url='/cron/session/' version='1.0' method='GET'></http></request>
</session>
```
4. Создаем сценарий тестирования. Tsung позволяет создать несколько сценариев, а также задать IP-адреса клиентов в том случае, если стоит распределитель нагрузки.
```
<?xml version="1.0"?>
<!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd">
<tsung loglevel="notice" version="1.0">

 <clients>
    <client host="localhost"  maxusers="300" use_controller_vm="true"/>
 </clients></b>

//Раздел servers для схемы с балансировщиком нагрузки, включен сюда, потому что tsung  ругается 571- fatal: {failed_validation,{no_xml_element,server}}  если не определён.
<b> <servers>
    <server host="192.168.1.1" port="80" type="tcp"></server> 
 </servers>

<load>
 <arrivalphase phase="1" duration="1" unit="minute">
    <users arrivalrate="10" unit="second"/>
 </arrivalphase>
</load>

//Сессия которая была записана ранее (в предыдущем пункте).
<session name='rec20121127-1403' probability='100'  type='ts_http'>
<request><http url='http://сайт/' version='1.0' method='GET'></http></request>
<request><http url='/thumbs/92_width_80.jpg' version='1.0' method='GET'></http></request>
<request><http url='/thumbs/93_width_80.jpg' version='1.0' method='GET'></http></request>
<request><http url='/thumbs/97_width_80.jpg' version='1.0' method='GET'></http></request>
<request><http url='/cron/session/' version='1.0' method='GET'></http></request>
</session>
```
5. Каждую секунду 10 новых пользователей выполняли сценарий:
  После выполнения нагрузочного тестирования можно сгенерировать отчет по логам, используя команду tsung-report.
  
  Графики в Zabbix(время с 14:30 – 14:50):
  
  Результат: Система стабильно работает с 300-ми пользователями, одновременно работающими с ее интерфейсом. При этом время формирования страницы для каждого пользователя не превышает 1 секунды.
  
  Полученные результаты на данном этапе развития, на наш взгляд, вполне допустимы для систем данного рода. Однако мы выявили ряд важных проблем, требующих решения и ещё раз убедились в необходимости усовершенствования системы.