Файл: Лабораторная работа 4 студент гр. Исэбд 31 Иванов И. И. Проверил Дырночкин А. А. Ульяновск, 2022г.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 09.01.2024
Просмотров: 83
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Среднее использование памяти при работе программы 80мб, загрузка ЦП <10%
Выводы
В рамках проведенного испытания были выявлены характеристики производительности приложения «APassManager» для заданной пользовательской нагрузки. На основании полученных результатов можно сделать выводы:
− Приложение может выдерживать большой набор данных в бд (более 30 000 записей в одной из таблиц);
− Наибольшее время система затрачивает на первый вход, т. к. во время первого входа происходит первое обращение к базе данных. Поэтому можно добавить при запуске системы пустое обращение к базе данных, чтобы потом пользователь не видел задержек при первом входе в систему.
− Характеристики производительности удовлетворяют условиям, система довольно быстро работает с заданным объемом данных (которых более чем достаточно и в реальных условиях пользователь вряд ли достигнет таких объемов) и не выходит за заданные границы по времени и по затраченной памяти.
Нагрузочное тестирование
Цели:
Получить показатели производительности системы в условиях высокой нагрузки. Сравнить показатели системы при средней нагрузке (30 000) и высокой (100 000)
Описание тестового стенда:
Процессор | Intel Core i3 7020U 2.3 GHz |
ОС | Windows 10 Professional x64 |
ОЗУ | 8GB |
Модель SSD | Samsung 860EVO 250GB |
Прочее | MS SQL Server Express 2019 .NET Framework 4.6.x Visual Studio 2019 |
Заполним базу данных 100 000 учетными записями (200 пользователей, у каждого пользователя 2 группы паролей и в каждой группе паролей по 250 учетных записей). Для заполнения будем использовать те же способы что и при тестировании производительности.
Для заполнения бд уже было затрачено куда больше времени и ОЗУ
Также выполним по 20 прогонов для каждой транзакции
Название транзакции | Минимум, с | Среднее, с | Максимум, с |
| 2,950388 | 3,070470 | 3,339526 |
| 0,012725 | 0,072307 | 0,129647 |
| 0,018619 | 0,022343 | 0,050450 |
| 0,102190 | 0,123474 | 0,169885 |
| 0,009154 | 0,009479 | 0,010346 |
| 0,069524 | 0,072510 | 0,077180 |
| 0,007594 | 0,010088 | 0,013661 |
| 0,007802 | 0,009692 | 0,015501 |
| 0,004500 | 0,009081 | 0,013749 |
| 0,007110 | 0,009353 | 0,014134 |
| 0,006443 | 0,010941 | 0,014515 |
| 1,294035 | 1,364817 | 1,472821 |
Сравнение результатов
По результатам сравнительных тестов можно сделать следующие выводы:
-
В среднем время отклика системы не изменилось от объема данных. -
Увеличилось время на регистрацию пользователя, на редактирование учетной записи и на загрузку учетных записей почти в два раза, но это не критично и по-прежнему удовлетворяет критериям производительности системы.
Теперь попробуем сгенерировать 100 тысяч пользователей и проверим сколько времени будет занимать авторизация в системе.
Пример сгенерированных данных:
Также прогоним 20 раз нашу модель и получим следующие результаты
В результате тестирования на 100 тысячах пользователей, была выявлена следующая закономерность. Чем больше id аккаунта в который пытается войти пользователь, тем дольше будет вход в систему. Вход в систему происходил за 0.016 – 0,077с, что по-прежнему удовлетворяет требованиям системы.