В одном из проектов перед нами стояла задача выгрузки из 1С на сайт большого количества товаров с периодичностью 2 раза в день. Хотим поделиться опытом, полученным при проведении нагрузочного тестирования проекта.
Мы изучили несколько статей на Хабре:
http://habrahabr.ru/post/77593/
http://habrahabr.ru/company/ontico/blog/95060/
http://habrahabr.ru/post/113914/
Сначала предстояло решить три вопроса:
- Что тестировать?
- Как проводить мониторинг полученных результатов?
- Как тестировать?
Начнем по порядку.
Что тестировать?
Наш стенд состоит из трёх основных элементов:
- Сервера 1С (Intel@Core i3-2125, 8 GB RAM)
- модуля PHP для обработки данных, пришедших из платформы 1С на сайт (Back-end REST Service)
- веб-интерфейса сайта
Основной функционал системы заключается в обмене xml-сообщениями между 1С и модулем обработки данных (REST), находящемся на сервере приложений. Модуль обработки получает данные из 1С и записывает их в базу данных. Веб–интерфейс сайта работает с базой данных.
Как проводить мониторинг полученных результатов?
В качестве средства мониторинга был выбран Zabbix — наиболее доступная система, которая отличается простотой в установке и использовании. Zabbix позволил нам не только наблюдать за процессом тестирования в режиме real-time, но и вести статистику, исходя из которой мы можем прогнозировать нагрузку и рассчитать значение показателей RPO (Recovery Point Objective) и RTO (Recovery Time Objective), а также доступность системы (Agreed Service Time).
Как тестировать?
Поскольку в системе можно выделить две основные части, постараемся выявить возможные изъяны именно в них. Первая — это взаимодействие шлюза 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
- Создадим сценарий, используя утилиту tsung-record. Tsung-record записывает действия клиента через прокси-сервер — Tsung Proxy. Остаётся прописать адрес прокси-сервера в браузере -127.0.0.1 и порт 8090, который будет слушать запросы.
И в терминале выполним команду tsung-record–star
- Открываем браузер и выполняем обычные действия пользователя:
● Просматриваем категории товаров;
● Осуществляем заказ товаров;
● Пользуемся поиском;
● Добавляем новый товар в заказ;Завершив работу в браузере, останавливаем tsung-recorder командой stop.
- В результате был создан файл, содержащий в себе 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> - Создаем сценарий тестирования. 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> - Каждую секунду 10 новых пользователей выполняли сценарий:
После выполнения нагрузочного тестирования можно сгенерировать отчет по логам, используя команду tsung-report.
Графики в Zabbix(время с 14:30 – 14:50):
Результат: Система стабильно работает с 300-ми пользователями, одновременно работающими с ее интерфейсом. При этом время формирования страницы для каждого пользователя не превышает 1 секунды.
Полученные результаты на данном этапе развития, на наш взгляд, вполне допустимы для систем данного рода. Однако мы выявили ряд важных проблем, требующих решения и ещё раз убедились в необходимости усовершенствования системы.
- Создадим сценарий, используя утилиту tsung-record. Tsung-record записывает действия клиента через прокси-сервер — Tsung Proxy. Остаётся прописать адрес прокси-сервера в браузере -127.0.0.1 и порт 8090, который будет слушать запросы.
Автор: Centrobit
