Ваш пример с телевизором не состоятелен, так как зрители не оказывают влияния на работу телевизора
С другой стороны, если у большинство клиентов работают с 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 хватит обычной рабочей станции.
Тест-центр, полагаю, учить всё равно надо - для моделирования толстого клиента, и, вероятно ради более точных метрик.
- встроенный в Chrome переводчик в разы лучше, чем то Г, которое встроено в Nightly-ветку FF (а в обычной ветке переводчика и вовсе нет) - сегодня обнаружил, что при скачивании с AWS S3 файла с расширением "file.tgz" я получаю "file.gz", который, конечно же, распаковывается некорректно.
после переименовывания обратно распаковывается корректно :)
Я 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 хватит обычной рабочей станции.
Тест-центр, полагаю, учить всё равно надо - для моделирования толстого клиента, и, вероятно ради более точных метрик.
О, это интересно!
А через Vanessa Automation можно создавать нагрузку отправкой трафика, моделируя сотни пользователей с одной нагрузочной странции?
Хочу добавить полезную информацию:
IO wait - на первый взгляд можно подумать, что процессор не делал чего-то полезного, потому что был занят ожиданием IO.
На самом деле это не так.
IO Wait можно отнести к подразделу Idle, то есть процессор простаивал без задач (наверное - да, потому, что задачи чего-то читали/писали).
Проверить это просто:
Загрузите процессор на 100% в категории IO wait а потом добавьте ему какую-нибудь задачку «на посчитать».
Вы увидите, что скорость IO не поменялась, а процессор при этом спокойно считает что-то ещё.
По wifi геолокация останется
Кажется
Тоже люблю FF, но всё же не могу не заметить:
- встроенный в Chrome переводчик в разы лучше, чем то Г, которое встроено в Nightly-ветку FF (а в обычной ветке переводчика и вовсе нет)
- сегодня обнаружил, что при скачивании с AWS S3 файла с расширением "file.tgz" я получаю "file.gz", который, конечно же, распаковывается некорректно.
после переименовывания обратно распаковывается корректно :)
Ну откройте сайт в «инкогнито», и никакого hsts
Нет, на самом деле нет. Отключают не все проверки, а только сертификата визы (а сертификатов там много в цепочке)
Ну, я так понял
В статье написано, что не так:
даже карты с ещё не истёкшим сроком действия могут получить такую проблему, потому что не обновлён корневой сертификат visa а не серт самой карты.
(Вот серт карты не должен истекать до конца срока действия карты, тут вы правы)
но в целом вы правы - замена этой карты в любом случае планировалась
Ахаха