хорошо - это когда в среднем утилизация ресурсов 10%-30% а в пиках 30%-60%
выше не стоит, потому что при 70%-80% система будет уже заметно тормозить а в облаках в некоторых ситуациях уже и после 40% становится заметно что времена отклика начинают расти
на самом деле это очень интересно - почему тесты приложения в докере могут выдавать результаты, сильно отличающиеся от того же приложения, не в докере.
В смысле - я не сомневаюсь в ваших результатах, но мне важно, в каких условиях они воспроизводятся (много работаю с приложениями в докере, хочется лучше понимать его ограничения) Можете рассказать о подходе к тестированию?
Для затравки я расскажу, как я это вижу: Интересен тест близкий к целевому, так что будем не просто нагружать проц а кидать HTTP-запросы - Нужно 2 сервера на Linux (источник нагрузки и объект тестирования) - на серверах выполняем настройки, типа увеличения диапазона портов, tw_reuse, всякое такое, чтобы настройки операционки не мешали Часть настроек можно взять отсюда https://docs.gatling.io/concepts/operations/
========== тест 1: запускаем приложение на сервере объекта тестирования
тест 2: Запускаем то же самом приложение на том же самом сервере, но в докер-контейнере. У контейнера прописаны Request достаточные, чтобы запустить приложение, а Limit не прописаны вовсе (можно прописать для лимит для памяти равный 80% от свободной оперативки на сервере, но для CPU) точно не нужно прописывать лимит, троттлинг может очень сильно зааффектить на приложение в контейнере ==========
Сами тесты одинаковые, со второго сервера подаём постепенно увеличивающуюся нагрузку. Смотрим где захлебнётся (прекратится рост производительности, начнут расти времена отклика или ошибки)
Для проверки лучше брать приложение, которое не работает с диском.
Будете ещё НТ делать - приходите к нам, в @QA_Load - тусовка НТшников в телеге. Если понадобится - поможем с анализом. У нас тепло, ошибки помогают найти а не ищут в них повода повыпендриваться осуждением
проф.деформация - мы видим только код с ошибками, а значит не видим в нём ничего "необычно-плохого".
Я работаю в НТ и часто встречаю "простые" ошибки даже у крутых разработчиков. Отсутствие кэширования, запрос в цикле..
Что уж говорить про мои собственные ошибки :) ============= Простые ошибки хороши тем, что ты их делаешь только один раз, и напоровшись единожды больше их не повторяешь. Но то, что комментатор в интернете про эту ошибку уже хорошо знает (напоровшись сам или прочитав яркую статью - типа вашей, кстати) - так вот, это не значит, что он сам никогда не совершал ДРУГУЮ простую ошибку.
PS А может и не совершал. Бывают крутые супервнимательные люди. Честь им и хвала! Жаль, что я не такой.
тут речь не о критике а о стиле критики. Скажите "если вы сделаете вот так или так - ваш код может получиться ещё лучше" - и человек к вам прислушается.
Скажите "детский сад" и человек пропустит все ценности вашего поста мимо ушей.
Ваш пример с телевизором не состоятелен, так как зрители не оказывают влияния на работу телевизора
С другой стороны, если у большинство клиентов работают с 1с через web-сервис, то создание нагрузки именно через web-сервер будет корректным способом воспроизведения этой самой нагрузки (не берусь судить, насколько удобным).
JMeter … не отдиагностирует медленное подыхание диска
Ну, тут надо отделять мух от котлет.
JMeter - это инструмент подачи нагрузки.
Он анализирует те клиентские метрики, которые ему доступны: количество возвращаемых ошибок, количество успешно выполненных операций, времена отклика.
А анализ работы системы, сбор её внутренних метрик а так же метрик составляющих ей систем (база данных, сеть и прочее) - это отдельная задача, выполняющаяся другими методами.
Это относится не только к 1с, так делается с любой системой
1с - это не сайт-визитка
Вы всё время это повторяете.
Я полагаю, что 1с - это классная система, не зря же она стала такой популярной. И код на русском - это на мой взгляд только помогает.
Я понимаю, что это система очень сложная и чтобы грамотно её протестировать, необходимо хорошо понимать, как она устроена.
Но я пока так и не увидел, чем она отличается от других ЕРП-систем, например SAP.
Мои коллеги тестировали SAP - с помощью JMeter и с помощью Load Runner.
С Load Runner было удобнее, так как в нём есть специальные рекордеры, облегчающие процесс записи и параметризации скрипта (проблемы, подобные описанным в статье).
Главное, что я хочу сказать - в SAP (как и в множестве других сложных систем) есть все те проблемы, которые вы описали. Они решаются (обычно глубоким анализом статистики и разработкой профиля тестирования совместно с разработчиками предприятия).
Я из комментариев в этом треде понял, что если репрезентативную нагрузку на систему можно создать несколькими пользователями, то лучше использовать тест-центр.
Что делать, если нельзя - пока ответа нет. Было бы здорово, если бы он появился, это пригодилось бы тем, кому понадобится тестировать 1с в дальнейшем
Вы правы в том, что 1с сильно отличается от «сайта-визитки», но проблемы, описанные вами (одна и та же операция, выполняемая с разными параметрами создаёт разную нагрузку) свойственны большинству сложных систем, которые я тестировал.
Это решается. Более того, эту проблему приходится решать при тестировании 1с «родным» по.
Я прочитал ваши ссылки, круто, спасибо за них. Покупать книгу не хотелось, всё же тестировать 1с мне не нужно, это просто любопытство.
Но я нашёл вот такую статью на хабре - выглядит очень интересно:
И тут коллеги запускают тесты «по 2 пользователя на сервере» на 6 серверах.
В нескорых ситуациях такой подход годится, в некоторых - нет.
Так вот, я хочу понять - есть ли какой-то аналог инструмента для создания массовой нагрузки на 1с через веб-сервер (сотни параллельно выполняющихся операций)?
Вы говорите, что jmeter не годится категорически - значит есть аналоги.
Ваш аналог - это запуск сотен серверов с тест-центром?
Уточню, я не против такого подхода - но в нагрузочном тестировании он используется только если нет другого выхода (в силу огромной ресурсоёмкости и дороговизны)
И почему нагрузку пренепременно нужно делать сотнями клиентов?
Потому что если нагрузку можно создать одним клиентом, то нагрузочное тестирование для этого не нужно - работник скажет "когда я запускаю отчёт, всё тормозит", а программист 1с повторит это и помощь инженеров по нагрузке ему не нужна.
Нагрузочное тестирование нужно как раз в тех случаях, когда моделирование нагрузки выходит за рамки работы (или за список обязанностей) разработчика.
Поэтому тестирование и делится на разные ветки - "ручное/автоматическое" или "нагрузочное".
И тут я возвращаюсь к своему вопросу: если 1с тормозит от того, что в ней работает много пользователей (а не от того, что кто-то запустил одну "тяжёлую" операцию) - как правильно её тестировать?
Предположим, у нас большая организация, тормоза начинаются когда в с 1с взаимодействуют множество менеджеров одновременно (скажем, 200 или 500) - что делать? Запускать 200-500 тест-центров или другой инструмент?
Я люблю нагрузочное тестирование, но с 1с у меня опыта нету а значит нет и ответа на этот вопрос, у вас есть, помогите понять! Спасибо.
Ну, в статье, конечно, очень многих деталей не хватает.
Из неё невозможно понять, что из этого делалось.
Если сперва был снять нормальный профиль нагрузки и запросы не «втупую» моделировались, то подход вполне рабочий. С ограничениями, конечно - но ограничения в НТ всегда есть
Ну вот и причина, по которой автор использовал JMeter для создания нагрузки.
Я так полагаю, 1000 тест-центров на одном компе запустить проблематично. А чтобы слать запросы в 1000 потоков из JMeter хватит обычной рабочей станции.
Тест-центр, полагаю, учить всё равно надо - для моделирования толстого клиента, и, вероятно ради более точных метрик.
ок, пожалуй согласен
хорошо - это когда в среднем утилизация ресурсов 10%-30% а в пиках 30%-60%
выше не стоит, потому что при 70%-80% система будет уже заметно тормозить
а в облаках в некоторых ситуациях уже и после 40% становится заметно что времена отклика начинают расти
на самом деле это очень интересно - почему тесты приложения в докере могут выдавать результаты, сильно отличающиеся от того же приложения, не в докере.
В смысле - я не сомневаюсь в ваших результатах, но мне важно, в каких условиях они воспроизводятся (много работаю с приложениями в докере, хочется лучше понимать его ограничения)
Можете рассказать о подходе к тестированию?
Для затравки я расскажу, как я это вижу:
Интересен тест близкий к целевому, так что будем не просто нагружать проц а кидать HTTP-запросы
- Нужно 2 сервера на Linux (источник нагрузки и объект тестирования)
- на серверах выполняем настройки, типа увеличения диапазона портов, tw_reuse, всякое такое, чтобы настройки операционки не мешали
Часть настроек можно взять отсюда
https://docs.gatling.io/concepts/operations/
==========
тест 1: запускаем приложение на сервере объекта тестирования
тест 2: Запускаем то же самом приложение на том же самом сервере, но в докер-контейнере.
У контейнера прописаны Request достаточные, чтобы запустить приложение, а Limit не прописаны вовсе (можно прописать для лимит для памяти равный 80% от свободной оперативки на сервере, но для CPU) точно не нужно прописывать лимит, троттлинг может очень сильно зааффектить на приложение в контейнере
==========
Сами тесты одинаковые, со второго сервера подаём постепенно увеличивающуюся нагрузку.
Смотрим где захлебнётся (прекратится рост производительности, начнут расти времена отклика или ошибки)
Для проверки лучше брать приложение, которое не работает с диском.
Будете ещё НТ делать - приходите к нам, в @QA_Load - тусовка НТшников в телеге. Если понадобится - поможем с анализом.
У нас тепло, ошибки помогают найти а не ищут в них повода повыпендриваться осуждением
проф.деформация - мы видим только код с ошибками, а значит не видим в нём ничего "необычно-плохого".
Так сказать, "ошибка невыжившего", ахаха :)
Я работаю в НТ и часто встречаю "простые" ошибки даже у крутых разработчиков.
Отсутствие кэширования, запрос в цикле..
Что уж говорить про мои собственные ошибки :)
=============
Простые ошибки хороши тем, что ты их делаешь только один раз, и напоровшись единожды больше их не повторяешь.
Но то, что комментатор в интернете про эту ошибку уже хорошо знает (напоровшись сам или прочитав яркую статью - типа вашей, кстати) - так вот, это не значит, что он сам никогда не совершал ДРУГУЮ простую ошибку.
PS А может и не совершал. Бывают крутые супервнимательные люди. Честь им и хвала!
Жаль, что я не такой.
тут речь не о критике а о стиле критики.
Скажите "если вы сделаете вот так или так - ваш код может получиться ещё лучше" - и человек к вам прислушается.
Скажите "детский сад" и человек пропустит все ценности вашего поста мимо ушей.
Очень спорное утверждение. Почему вы так считаете?
а на сколько% железо должно быть использовано в пике, по вашему мнению?
20% это имхо как раз хорошо (пока денег на такое железо хватает)
как много "злых" комментов.
Это печально.
Все совершают ошибки, такие статьи помогают их избегать.
Статья интересная, спасибо за неё!
Я HD Tune предпочитал
Ну значит началось со смерти TJ
Прочитал вашу ссылку и понял, что сперва неверно вас понял :)
Вы писали про подключение к одному серверу 1с а я решил что это подключение от имени одного пользователя 1с
спасибо за инфу!
Оо, спасибо вам большое!
После вашего сообщения перечитал тот пост а потом ещё нашёл ещё такой ролик:
https://youtu.be/ByheuXihhuE?si=ATBLxD_4qosTBi6S
тут прямо в деталях показывается, как подавать нагрузку через тест-центр (в том числе регулировать количество пользователей).
Класс, я получил свои ответы, спасибо!
Ну, чтож.
Оставим тред тому, кто "и так знает".
Ответы ему не нужны, он и так знает.
А я поищу их где-нибудь ещё :)
Спасибо за беседу.
Ваш пример с телевизором не состоятелен, так как зрители не оказывают влияния на работу телевизора
С другой стороны, если у большинство клиентов работают с 1с через web-сервис, то создание нагрузки именно через web-сервер будет корректным способом воспроизведения этой самой нагрузки (не берусь судить, насколько удобным).
Ну, тут надо отделять мух от котлет.
JMeter - это инструмент подачи нагрузки.
Он анализирует те клиентские метрики, которые ему доступны: количество возвращаемых ошибок, количество успешно выполненных операций, времена отклика.
А анализ работы системы, сбор её внутренних метрик а так же метрик составляющих ей систем (база данных, сеть и прочее) - это отдельная задача, выполняющаяся другими методами.
Это относится не только к 1с, так делается с любой системой
Вы всё время это повторяете.
Я полагаю, что 1с - это классная система, не зря же она стала такой популярной. И код на русском - это на мой взгляд только помогает.
Я понимаю, что это система очень сложная и чтобы грамотно её протестировать, необходимо хорошо понимать, как она устроена.
Но я пока так и не увидел, чем она отличается от других ЕРП-систем, например SAP.
Мои коллеги тестировали SAP - с помощью JMeter и с помощью Load Runner.
С Load Runner было удобнее, так как в нём есть специальные рекордеры, облегчающие процесс записи и параметризации скрипта (проблемы, подобные описанным в статье).
Главное, что я хочу сказать - в SAP (как и в множестве других сложных систем) есть все те проблемы, которые вы описали. Они решаются (обычно глубоким анализом статистики и разработкой профиля тестирования совместно с разработчиками предприятия).
Я из комментариев в этом треде понял, что если репрезентативную нагрузку на систему можно создать несколькими пользователями, то лучше использовать тест-центр.
Что делать, если нельзя - пока ответа нет. Было бы здорово, если бы он появился, это пригодилось бы тем, кому понадобится тестировать 1с в дальнейшем
А я и не берусь за тестирование 1с :)
Мне просто любопытно, как это делать.
Вы правы в том, что 1с сильно отличается от «сайта-визитки», но проблемы, описанные вами (одна и та же операция, выполняемая с разными параметрами создаёт разную нагрузку) свойственны большинству сложных систем, которые я тестировал.
Это решается. Более того, эту проблему приходится решать при тестировании 1с «родным» по.
Я прочитал ваши ссылки, круто, спасибо за них. Покупать книгу не хотелось, всё же тестировать 1с мне не нужно, это просто любопытство.
Но я нашёл вот такую статью на хабре - выглядит очень интересно:
https://habr.com/ru/articles/696790/
И тут коллеги запускают тесты «по 2 пользователя на сервере» на 6 серверах.
В нескорых ситуациях такой подход годится, в некоторых - нет.
Так вот, я хочу понять - есть ли какой-то аналог инструмента для создания массовой нагрузки на 1с через веб-сервер (сотни параллельно выполняющихся операций)?
Вы говорите, что jmeter не годится категорически - значит есть аналоги.
Ваш аналог - это запуск сотен серверов с тест-центром?
Уточню, я не против такого подхода - но в нагрузочном тестировании он используется только если нет другого выхода (в силу огромной ресурсоёмкости и дороговизны)
Потому что если нагрузку можно создать одним клиентом, то нагрузочное тестирование для этого не нужно - работник скажет "когда я запускаю отчёт, всё тормозит", а программист 1с повторит это и помощь инженеров по нагрузке ему не нужна.
Нагрузочное тестирование нужно как раз в тех случаях, когда моделирование нагрузки выходит за рамки работы (или за список обязанностей) разработчика.
Поэтому тестирование и делится на разные ветки - "ручное/автоматическое" или "нагрузочное".
И тут я возвращаюсь к своему вопросу: если 1с тормозит от того, что в ней работает много пользователей (а не от того, что кто-то запустил одну "тяжёлую" операцию) - как правильно её тестировать?
Предположим, у нас большая организация, тормоза начинаются когда в с 1с взаимодействуют множество менеджеров одновременно (скажем, 200 или 500) - что делать? Запускать 200-500 тест-центров или другой инструмент?
Я люблю нагрузочное тестирование, но с 1с у меня опыта нету а значит нет и ответа на этот вопрос, у вас есть, помогите понять!
Спасибо.
У вас если есть понимание, как создавать большую нагрузку на 1с (пусть даже только через веб) - скажите пожалуйста.
всё делать только через тест-сервер, используя 100500 нагрузочных станций?
Или есть другие тулы, которые могут моделировать хотя бы сотни клиентов с одного компа?
Спасибо.
Ну, в статье, конечно, очень многих деталей не хватает.
Из неё невозможно понять, что из этого делалось.
Если сперва был снять нормальный профиль нагрузки и запросы не «втупую» моделировались, то подход вполне рабочий. С ограничениями, конечно - но ограничения в НТ всегда есть
А какой подход к тестированию предложили бы вы?
Как смоделироаать большую нагрузку?
Спасибо за ответ!
Ну вот и причина, по которой автор использовал JMeter для создания нагрузки.
Я так полагаю, 1000 тест-центров на одном компе запустить проблематично. А чтобы слать запросы в 1000 потоков из JMeter хватит обычной рабочей станции.
Тест-центр, полагаю, учить всё равно надо - для моделирования толстого клиента, и, вероятно ради более точных метрик.