+7 (499) 346-66-97
+7 (812) 424-78-06
Позвонить нам на скайп
  • Автоматизация продаж SugarCRM

    CRM-решения позволяют автоматизировать учет клиентов и осуществлять грамотное руководство работой менеджеров с клиентами.

  • Задачи и проекты Bitrix24

    Самая популярная CRM-система в России от компании 1С-Битрикс. Облачный сервис, социальная сеть, управление проектами и задачами.

  • Телефония
    Asterisk

    Основная задача для компаний, устанавливающих решения по телефонии – организовать надежную, удобную и экономичную телефонию.

  • Автоматизация
    документооборота
    Alfresco

    СЭД позволяют повысить эффективность управления компанией и исполнительскую дисциплину, снизить затраты на работу с документами.

  • Автоматизация продаж Vtiger

    CRM, представляет собой совокупность программ, позволяющих автоматизировать взаимодействие с клиентами.

  • Управление проектами Trac

    Open Source платформа Trac предназначена для контроля и ведения проектов и проектных задач.

  • Управление проектами SuiteCRM

    Open Source платформа Trac предназначена для контроля и ведения проектов и проектных задач.

Развернуть

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

Нагрузочное тестирование SugarCRM, SuiteCRM, vTigerCRM.

Компания «Куб Три» предлагает услугу нагрузочного тестирования решений на базе CRM платформ.
Это необходимо для компаний с количеством пользователей больше 200.

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

Четких границ между данными понятиями не существует. Равно как и исследование по каждому из направлений не позволяет комплексно оценить реакцию системы на высокие нагрузки.

Нагрузочные исследование веб-приложений, к которым относится CRM система, имеют особенности. В частности, работа каждого компонента структуры программных веб-систем и их взаимодействие оказывает влияние на показатели работы системы под нагрузкой. Типичными компонентами веб-систем являются веб-сервер, менеджер процессов приложения, сервер БД. Дополнительную сложность в реализации сложный программных систем в виде веб-приложений является ограничение протоколов HTTP/HTTPS, не позволяющее хранить состояние между запросами от клиента к серверу.

Проекты по тестированию реализовывались на разных СУБД – Oracle, MySQL, PostgreSQL.
Тестирование проводится Исполнителем следующим образом:

  1. Разрабатывается ряд (5-10) сценариев работы пользователя, которые проверяются под нагрузкой. Например, должны быть проведены следующие сценарии: два обобщенных сценария на всю систему, по одному-два на каждый модуль. Один сценарий на поиск.
  2. Генерируется 1млн записей клиентов (и/или любых других модулей).
  3. Делается одновременно (с помощью специализированного ПО) необходимое количество (в зависимости от планируемого количества пользователей) подключений.
  4. Предоставляется отчет по результатам тестирования, включающий в себя мониторинг загрузки аппаратных средств сервера в момент нагрузочного тестирования.

Программное обеспечение с настройкой и файлы сценариев тестирования, инструкции по формированию и выполнению тест-кейсов передаются клиенту для дальнейшего повторения тестов на промышленной системе.

Постановка задачи для нагрузочного тестирования
Оценка показателей производительности и аппаратных средств системы при нагрузочном тестировании

  1. оценка поведения системы в экстремальных условиях (пиковых нагрузках) и способность системы к восстановлению после прекращения воздействия стресса: определение показаний нагрузки, при которых система отвечает требованиям; тестирование емкости системы.
  2. оценка возможности системы работать длительное время под нагрузкой, например в течение 24 и более часов при средней нагрузке порядка 80% от максимальной и измерение показателей: время выполнения операций; распределение системных ресурсов; другие показатели с учетом особенности системы.
  3. определение максимальной производительности системы: наибольшая интенсивность выполнения операций с требуемым качеством обслуживания; пиковая производительность системы, при которой происходит ухудшение показателей (время выполнения и отказы).

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

  1. Время отклика
  2. Загрузка процессора(CPU)
  3. Загрузка памяти(Memory)
  4. Кол-во используемой памяти, дисковое и сетевое i/o (Disks I/O и Networks I/O)
  5. Загрузка файла подкачки(Swap)
  6. Интенсивность
  7. Определение максимального числа пользователей в условиях заданной конфигурации системы

Примеры сценариев:

Сценарий №1: авторизация нескольких пользователей (вход в систему), загрузка Главной страницы и выполнение Глобального поиска.

Сценарий №2: авторизация нескольких пользователей (вход в систему), переход в список модуля Отчеты, переход в форму просмотра отчета по Контрагентам, загрузка отчета по Контрагентам, переход в список модуля Отчеты, переход в форму просмотра отчета по Холдингам, загрузка отчета по Холдингам, переход в список модуля Отчеты, переход в форму просмотра отчета по Сделкам и загрузка отчета по Сделкам.

Сценарий №3: авторизация нескольких пользователей (вход в систему), переход в список модуля Контрагенты, создание Контрагента, переход в список модуля Контрагенты, переход в форму просмотра Контрагента(открытие карточки контрагента) и создание Адреса контрагента через субпанель в карточке контрагента.

Тесты на основе сценариев

Тест №1 «Одновременная авторизация пользователей и выполнение Глобального поиска»:

  1. Условия теста: одновременная авторизация пользователей, загрузка Главной страницы и выполнение Глобального поиска (сценарий №1)
  2. Количество Виртуальных пользователей: 304
  3. Количество итераций: 1
  4. Задержка между итерациями: 0sec
  5. Результаты: (результаты теста в виде таблиц и графиков)
  6. Показатели: (Время отклика, Интенсивность, Загрузка процессора, Кол-во используемой памяти, дисковое и сетевое i/o, Определение максимального числа пользователей в условиях заданной конфигурации системы)

Тест №2 «Последовательная авторизация пользователей и выполнение Глобального поиска»:

  1. Условия теста: последовательная авторизация пользователей в течение 600сек, загрузка Главной страницы и выполнение Глобального поиска (сценарий №1)
  2. Количество Виртуальных пользователей: 304
  3. Количество итераций: 1
  4. Задержка между итерациями: 600sec
  5. Результаты: (результаты теста в виде таблиц и графиков)
  6. Показатели: (Время отклика, Интенсивность, Загрузка процессора, Кол-во используемой памяти, дисковое и сетевое i/o, Определение максимального числа пользователей в условиях заданной конфигурации системы)

Тест №3 «Последовательная авторизация пользователей и выполнение Глобального поиска»:

  1. Условия теста: последовательная авторизация пользователей в течение 3600сек, загрузка Главной страницы и выполнение Глобального поиска (сценарий №1)
  2. Количество Виртуальных пользователей: 304
  3. Количество итераций: 1
  4. Задержка между итерациями: 3600sec
  5. Результаты: (результаты теста в виде таблиц и графиков)
  6. Показатели: (Время отклика, Интенсивность, Загрузка процессора, Кол-во используемой памяти, дисковое и сетевое i/o, Определение максимального числа пользователей в условиях заданной конфигурации системы)

Примеры результатов исследований

Значения показателей

Тест №1: Сценарий №1, 304 пользователя, 1 итерация, время увеличения: 0 с

Результаты теста приведены в таблицах 2, 3.


Таблица 2

 

Max

Min

Average

Время ответа, мс

152660

0

1815,413


Таблица 3

 

Ошибка 502

Общий процент ошибочных ответов во всем тесте

Количество ошибочных ответов

475

2,9%

Тест №2: Сценарий №1, 304 пользователя, 1 итерация, время увеличения: 600 с

Результаты теста приведены в таблицах 4, 5.


Таблица 4

 

Max

Min

Average

Время ответа, мс

2858

0

100,1006


Таблица 5

 

Ошибка 502

Общий процент ошибочных ответов во всем тесте

Количество ошибочных ответов

0

0 %

Тест №3: Сценарий №1, 304 пользователя, 10 итераций, время увеличения: 600 с

Результаты теста приведены в таблицах 6, 7.


Таблица 6

 

Max

Min

Average

Время ответа, мс

453665

0

2573,17


Таблица 7

 

Ошибка 502

Ошибка 500

Ошибка 404

Общий процент ошибочных ответов во всем тесте

Количество ошибочных ответов

4271

1

70

2,6 %

Примеры выводов от исследований

Выделение ограничивающих факторов

По результатам имитации рабочеи? и высокои? нагрузки (тесты с 10 итерациями и временем подключения 600 с, тесты с «мгновенным» подключениям пользователеи? — 0 с, 10 итерации? и 3600 с) видно, что основным ограничивающим фактором производительности системы является ресурс центрального процессора сервера приложении?. В указанных тестах в среднем более 90% времени теста загрузка процессора имеет значения близкие к 100%.

Поведение при низкои? и рабочеи? нагрузке (600 — 1, 3600 — 10)

Для большинства сценариев рабочая и низкая нагрузка не приводит к достижению ограничения используемых ресурсов сервера приложении? и появлению ошибок в ответах. Однако в тестах сделок и задач рабочая и низкая нагрузка на систему приводит к появлению ошибок в ответах. Из этого следует вывод о возможных функциональных ошибках в соответствующих модулях.

Поведение при возрастании нагрузки (0 — 1, 600 — 10)

Для всех тестовых сценариев пиковая и повышенная нагрузка приводит к появлению ошибок в ответах сервера. Совместно с данными по утилизируемым ресурсам для этих следует сделать вывод, что ресурсы стенда, на котором производились исследования, не позволяют обеспечить сервис системы при повышении нагрузке до указанных значении?.

Выполнение требовании? к производительности системы

Тесты рабочеи? нагрузки показывают, что утилизация ресурса процессора в этих случаях составляет значения близкие к максимальным, а время отклика системы существенно превышает требования ко времени обновления экраннои? формы. При этом утилизация ресурса центрального процессора составляет значения близкие к 100%. Таким образом следует заключить о недостатке ресурсов тестового стенда для указаннои? нагрузки.

Отдельно следует отметить результаты при среднеи? нагрузке (тесты 600 — 1). В данных тестах видно, что происходит достижение максимальнои? утилизации ресурсов сервера приложении?, время отклика существенно превышает требования. В частности, в тестах сделок и задач доля запросов время отклика которых укладывается в требуемые значения составляет 4.18% и 9.87% соответственно. Данныи? факт позволяет сделать вывод о необходимости проведения исследовании? для поиска дополнительных сдерживающих факторов. К таким факторам могут относится, например, производительность сетеи? передачи данных, сервера БД.

Отдельные особенности

Результаты теста построения отчетов имеют следующие особенности: утилизация ресурсов сервера приложении? имеет ярко выраженные неравномерности. Вместе с этим данные тесты не продуцируют ошибочных ответов. Данные факты свидетельствую о том, что наиболее вероятным ограничивающим фактором в данных тестах не являются ресурсы сервера приложении? и следует обратить внимание на поведения сервиса БД при построении отчетов. Можно заключить, что при построении отчетов сервер приложении? формирует «тяжелые» запросы к БД и ожидает их выполнения.

Увеличение производительности

Из п. 5.1 — 5.5 видно, что для обеспечения требуемых показателеи? системы следует повышать проводить реорганизацию инфраструктуры, обеспечивающеи? сервис CRM. Обобщая направления развития можно выделить два подхода: экстенсивныи? и интенсивныи?.

Первыи? подход связан с увеличением ресурсов сервера приложения. При этом под увеличением ресурсов понимается не только возможное увеличение количества ресурсов центрального процессора (увеличение чиста процессорных ядер и их производительности), но и кластеризация инфраструктуры сервиса — передача функции? сервера приложении? некоторому набору узлов, имеющих общии? механизм пользовательских сессии?. При этом пользовательские запросы к системе распределяются между узлами кластера, что повышает производительность системы и является путем для повышения отказоустои?чивости. Интенсивныи? путь повышения производительности связан с анализом и последующим архитектурным и/или реализационным рефакторингом системы. Оба пути имеют ограничения по увеличению производительности. Могут быть использованы совместно.

Примеры графиков на основе исследований

Показатель

Значение

Доля ответов, удовлетворяющих требованию ко времени отклика (5 с), %

0.22%

Минимальное время отклика, мс

2264

Максимальное время отклика, мс

190546

Среднее время отклика, мс

44930.09

Количество ошибочных ответов

479

Доля ошибочных ответов

2,92%

График 3. Изменение интенсивности возникновения ошибок по времени тестирования

График 4. Изменение времени ответа сервера по времени тестирования

График 5. Распределение количества запросов по времени ответа

График 6. Утилизация ресурсов сервера приложения

Позвоните нам и мы ответим на все ваши вопросы!

8 (812) 424-78-06
8 (499) 346-66-97

или свяжитесь с нами по форме обратной связи

Написать сообщение

Отправить