Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(2) в очередной раз статья убеждает что честный нормальный тест в фирме 1С не делают (только фикцию какую то) )))
нагрузка в 80% для 40 ядер это многовато, какие то ядра значит лежат под 100%, некоторые тормоза начинаются с общей загрузки в 50%
40 ядер для 5000 в реальности мало под типовую ЕРП, её надо либо сильно допиливать, либо более мощное железо подкладывать
и я всё жду когда кто то всё таки напишет нормальный ОБЪЕМНЫЙ тест, ведь при такой интенсивности блокировки вследствии террабайт базы будут большей проблемой чем железо с нагрузочным тестом
статья хорошая и полезная, особенно тем кто задают вопрос можно ли на постгрессе впринципе запустить толпу народу
нагрузка в 80% для 40 ядер это многовато, какие то ядра значит лежат под 100%, некоторые тормоза начинаются с общей загрузки в 50%
40 ядер для 5000 в реальности мало под типовую ЕРП, её надо либо сильно допиливать, либо более мощное железо подкладывать
и я всё жду когда кто то всё таки напишет нормальный ОБЪЕМНЫЙ тест, ведь при такой интенсивности блокировки вследствии террабайт базы будут большей проблемой чем железо с нагрузочным тестом
статья хорошая и полезная, особенно тем кто задают вопрос можно ли на постгрессе впринципе запустить толпу народу
Несколько узковато набок тестируемых задач.
Яб добавил в список хотябы открытие форм справочников/документов.
К примеру замечена проблема с ОС, открытия справочника на Postgres SQL (релизах 2.5.7.402 - 2.5.8.179).
Яб добавил в список хотябы открытие форм справочников/документов.
К примеру замечена проблема с ОС, открытия справочника на Postgres SQL (релизах 2.5.7.402 - 2.5.8.179).
(3)Вы видимо не читали статью или о чем-то другом. В рамках нагрузочного теста выполнялась полная имитация работы пользователей по ролям - методология описана тут . Это включает в себя создание документов, работа с динамическими списками, АРМ, поиск в динамических списках, открытие отчетов, проведение, заполнение данными. Все по взрослому. И таких ролевых ботов в базу мы запускали в количества 350+. Если каких-то операций не хватает, типа всех кнопки нажимальщика, можно при необходимости добавить.
(5) Пример схему бизнес-процесса "продажи" можете посмотреть тут: . Обратите внимание на дорожки для которых указан исполнитель.
Подобные схемы описания используются для двух других процессов. Что происходит, как создавались под них сценарии действий можете ознакомиться в видео-уроках (только в текущем случае используется API selenium):
Подобные схемы описания используются для двух других процессов. Что происходит, как создавались под них сценарии действий можете ознакомиться в видео-уроках (только в текущем случае используется API selenium):
(6) Работает значительно шустрее, по результатам перевода продуктовой базы на PG 14 в ERP часть проблемных запросов просто исчезла. Не только с временными таблицами, но и планировщик стал более умным.
(12) Вы же рядом там где-то с 1С, спросите у них почему.
Я основывался на следующих фактах:
1. Нам был официальный ответ про то что это API не предназначено для выполнения нагрузочного тестирования. Когда мы пробовали выполнить работы, на наш вопрос почему сервер уходит в себя при такой незначительной нагрузке.
2. Я специально провел тест на машине (результаты которого описал), думал что-то изменилось на текущий момент. Но 6 клиентов буквально положили 4х ядерный 8 ГБ виртуальный сервер для формирования нагрузки, в момент когда началось активная работа. У меня создалось впечатление что каждый клиент отжирал по 10-20%. При переключении работы на Selenuim, мы легко смогли запустить до 12 клиентов.
3. К тому же у нас есть сервер для выполнения сборки релиза и он буквально под 80-90% процентов нагружается, когда идет сценарный тест по ролям, в нем запускается 10 клиентов под ролями.
В приведенной Вами статье:
- Я не вижу графиков нагрузки оборудования, не вижу графики параметров сервисов 1С. Это очень важно. Вообще нет ничего привязанного к временной шкале.
- Приведенный тест на 50 пользователей, это не о чем. В текущем ключе вы вполне можете не увидеть паразитной загрузки сервера взаимодействием в рамках API 1C Automation UI, а то что на клиентах греется воздух на это не обращают внимание.
- Есть отчет со значениями APDEX (время операции). Но вы учтите что эти 50 клиентов могут нажимать по очереди кнопки в течении 1-го часа. И показатели будут шикарными. Нет временного интервала.
В ней делается акцент на больше на процесс написания скриптов и последовательности действий. Если это переложить на Selenium, то думаю что станет адекватно.
Очень странно, что в сообществе почему-то считают что API от 1С, можно использовать в нагрузочном тестировании.
Я основывался на следующих фактах:
1. Нам был официальный ответ про то что это API не предназначено для выполнения нагрузочного тестирования. Когда мы пробовали выполнить работы, на наш вопрос почему сервер уходит в себя при такой незначительной нагрузке.
2. Я специально провел тест на машине (результаты которого описал), думал что-то изменилось на текущий момент. Но 6 клиентов буквально положили 4х ядерный 8 ГБ виртуальный сервер для формирования нагрузки, в момент когда началось активная работа. У меня создалось впечатление что каждый клиент отжирал по 10-20%. При переключении работы на Selenuim, мы легко смогли запустить до 12 клиентов.
3. К тому же у нас есть сервер для выполнения сборки релиза и он буквально под 80-90% процентов нагружается, когда идет сценарный тест по ролям, в нем запускается 10 клиентов под ролями.
В приведенной Вами статье:
- Я не вижу графиков нагрузки оборудования, не вижу графики параметров сервисов 1С. Это очень важно. Вообще нет ничего привязанного к временной шкале.
- Приведенный тест на 50 пользователей, это не о чем. В текущем ключе вы вполне можете не увидеть паразитной загрузки сервера взаимодействием в рамках API 1C Automation UI, а то что на клиентах греется воздух на это не обращают внимание.
- Есть отчет со значениями APDEX (время операции). Но вы учтите что эти 50 клиентов могут нажимать по очереди кнопки в течении 1-го часа. И показатели будут шикарными. Нет временного интервала.
В ней делается акцент на больше на процесс написания скриптов и последовательности действий. Если это переложить на Selenium, то думаю что станет адекватно.
Очень странно, что в сообществе почему-то считают что API от 1С, можно использовать в нагрузочном тестировании.
(14)
Я надеюсь, что вы понимаете, что трафик ходит разными путями для клиента тестирования как тонкого клиента и для клиента тестирования как web клиента. Если клиент тестирования запущен как web клиент - то трафик от менеджера тестирования к клиенту тестирования действительно будет ходить через сервер 1С.
Если клиент тестирования запущен как тонкий клиент не вижу проблем для запуска нагрузочного теста.
Я надеюсь, что вы понимаете, что трафик ходит разными путями для клиента тестирования как тонкого клиента и для клиента тестирования как web клиента. Если клиент тестирования запущен как web клиент - то трафик от менеджера тестирования к клиенту тестирования действительно будет ходить через сервер 1С.
Если клиент тестирования запущен как тонкий клиент не вижу проблем для запуска нагрузочного теста.
(16) вот такой ответ пришел нам, запрашивали через коллег:
От компании «1С» получили официальный ответ: "что клиент тестирования и менеджер тестирования не предназначены и не проектировались под использование в нагрузочных тестах."
Может кто-то спросит у 1С еще раз - подтвердит или опровергнет данное сообщение. Я очень не люблю общаться с поддержкой 1С, только когда иного выхода нет.
От компании «1С» получили официальный ответ: "что клиент тестирования и менеджер тестирования не предназначены и не проектировались под использование в нагрузочных тестах."
Может кто-то спросит у 1С еще раз - подтвердит или опровергнет данное сообщение. Я очень не люблю общаться с поддержкой 1С, только когда иного выхода нет.
Хотелось бы конечно более развернутого описания, почему Автор приравнивает работу 350 ботов к работе 5000 реальных пользователей.
Может есть какая-то доказательная база?
По моим расчетам, даже если взять Ваши слова за истину, то получится следующий расчет:
350 ботов = 5000 пользователей, т.е. 1 бот = 14 пользователей.
Почему далее по тексту статьи говорится про то, что 200 ботов это 2000 пользователей (хотя 200 *14 = 2800). Допущение в 30% это крайне не точная оценка.. Каким образом получена корреляция времени вызовов к количеству пользователей онлайн? Без этого понимания крайне сложно сделать корректную оценку результатов тестирования.
Может есть какая-то доказательная база?
По моим расчетам, даже если взять Ваши слова за истину, то получится следующий расчет:
350 ботов = 5000 пользователей, т.е. 1 бот = 14 пользователей.
Почему далее по тексту статьи говорится про то, что 200 ботов это 2000 пользователей (хотя 200 *14 = 2800). Допущение в 30% это крайне не точная оценка.. Каким образом получена корреляция времени вызовов к количеству пользователей онлайн? Без этого понимания крайне сложно сделать корректную оценку результатов тестирования.
(10) В самом начале привел описание и выделил жирным формулу, получается не совсем понятно ,поправим:
1. Критерий оценки - сколько пользователей сервис 1С может обслуживать одномоментно. Проще можно сказать так: 1500+ пользователей одновременно будут нажимать 50 клавиш и наши боты будут делать столько же нажатий. Поэтому можно считать что тесты эквивалентны.
2. количество обращений к сервисам 1С в ед. времени = количество пользователей онлайн * от 4% до 6%
и обратная формула:
количество пользователей онлайн = количество обращений к сервисам 1С в ед. времени/от 4% до 6%
где количество обращений к сервисам 1С в ед. времени - это очередь время вызова (текущее) (отражает нагрузку 1С)
и очередь время захвачено СУБД (отражает нагрузку на СУБД)
Имеем очередь в 200 обращений -> 200/0.04=5000
1. Критерий оценки - сколько пользователей сервис 1С может обслуживать одномоментно. Проще можно сказать так: 1500+ пользователей одновременно будут нажимать 50 клавиш и наши боты будут делать столько же нажатий. Поэтому можно считать что тесты эквивалентны.
2. количество обращений к сервисам 1С в ед. времени = количество пользователей онлайн * от 4% до 6%
и обратная формула:
количество пользователей онлайн = количество обращений к сервисам 1С в ед. времени/от 4% до 6%
где количество обращений к сервисам 1С в ед. времени - это очередь время вызова (текущее) (отражает нагрузку 1С)
и очередь время захвачено СУБД (отражает нагрузку на СУБД)
Имеем очередь в 200 обращений -> 200/0.04=5000
(10) если оценивать грубо, то для оценки работы субд такое упрощение приемлемо, там действительно будет соизмеримая интенсивность запросов
если оценивать приложения на толстом клиенте то тоже достоверно
если оценивать тонкий клиент, то упрощение не точно хотя бы потому что нет идентичных процессов типа быстрого поиска по полнотекстовому поиску, недостаточно много одновременных быстрых запросов по отрисовке форм и другие нюансы, но если нужно за вменяемые деньги получить хоть какую то картину для "начальной точки отчета" это всё равно наилучший вариант
вы же в фоновиках всё равно интерактивные операции идентично не сгенерите, а често стартовать 5000 клиентов это 5000 лицензий клиентских корп выложить надо, но и это не всё, по идее еще надо 40 терминалок, я таких практически не видел, поэтому в данном случае это разумный РЕАЛИСТИЧНЫЙ компромис
если оценивать приложения на толстом клиенте то тоже достоверно
если оценивать тонкий клиент, то упрощение не точно хотя бы потому что нет идентичных процессов типа быстрого поиска по полнотекстовому поиску, недостаточно много одновременных быстрых запросов по отрисовке форм и другие нюансы, но если нужно за вменяемые деньги получить хоть какую то картину для "начальной точки отчета" это всё равно наилучший вариант
вы же в фоновиках всё равно интерактивные операции идентично не сгенерите, а често стартовать 5000 клиентов это 5000 лицензий клиентских корп выложить надо, но и это не всё, по идее еще надо 40 терминалок, я таких практически не видел, поэтому в данном случае это разумный РЕАЛИСТИЧНЫЙ компромис
(26)Опять соглашусь.
Вопросы отрисовки и всякие сопутствующие служебные моменты учесть можно только запустив идентичное количество. И создавать полную модель - это очень затратно. Мы ограничились определенным набором действий, что было достаточно. Для учета этих отклонений накинули запас в 20%-30%.
Хоть текущая концепция и позволяет выполнить тест и с реальным количеством запущенных пользователей, добавить больший перечень операций, но думаю на это не пойдет и сама 1С.
Вопросы отрисовки и всякие сопутствующие служебные моменты учесть можно только запустив идентичное количество. И создавать полную модель - это очень затратно. Мы ограничились определенным набором действий, что было достаточно. Для учета этих отклонений накинули запас в 20%-30%.
Хоть текущая концепция и позволяет выполнить тест и с реальным количеством запущенных пользователей, добавить больший перечень операций, но думаю на это не пойдет и сама 1С.
(26)
Интересная ситуация будет когда клиент основываясь на данных прикидках построит свой продакшн, а по итогу из-за некорректно построенной системы потеряет десяток-другой миллионов.. реалистичный компромис может стоить вполне реальных денег…
При этом я не утверждаю что теория высказанная в статье некорректна, наоборот хочется объективного подтверждения что она корректна
Интересная ситуация будет когда клиент основываясь на данных прикидках построит свой продакшн, а по итогу из-за некорректно построенной системы потеряет десяток-другой миллионов.. реалистичный компромис может стоить вполне реальных денег…
При этом я не утверждаю что теория высказанная в статье некорректна, наоборот хочется объективного подтверждения что она корректна
(34)
на вопрос корректности должен отвечать Заказчик
вы ему говорите - вот с упрощением тест стоит миллион, у него такие то риски
полностью идентичный со всеми терминалками, лицензиями и блэкджеком, когда в будущем код изменится риски тоже возникнут - 150 миллионов (и то с суммой я наверняка ошибся, сейчас лицензии и железо на такую толпу стоят больше)
вы какой вариант выбираете...
на вопрос корректности должен отвечать Заказчик
вы ему говорите - вот с упрощением тест стоит миллион, у него такие то риски
полностью идентичный со всеми терминалками, лицензиями и блэкджеком, когда в будущем код изменится риски тоже возникнут - 150 миллионов (и то с суммой я наверняка ошибся, сейчас лицензии и железо на такую толпу стоят больше)
вы какой вариант выбираете...
Спасибо за статью!
> Мы сделали вывод и еще раз подтвердили рекомендации компании 1С— нельзя тестировать нагрузку через API 1С Automation UI
А можете ссылку дать? Дело в том, что мы успешно тестируем сотни тонких клиетов через 1С Automation UI, и на довольно старом оборудовании. Каждый клиент, отдельная маленькая виртуальная машина под линуксом.
> Мы сделали вывод и еще раз подтвердили рекомендации компании 1С— нельзя тестировать нагрузку через API 1С Automation UI
А можете ссылку дать? Дело в том, что мы успешно тестируем сотни тонких клиетов через 1С Automation UI, и на довольно старом оборудовании. Каждый клиент, отдельная маленькая виртуальная машина под линуксом.
(17)
Во-первых, я веду речь про нагрузочное тестирование.
Для сценарных тестов это самое то и удобное. Одно из лучших API.
Во-вторых, у меня совсем не срослось нагрузочное тестирование в этом API. Если у вас работает и вас устраивают результаты, ваше право.
Думаю, что мы выложим наработки в некотором будущем и можно будет проверить независимо эти выводы.
Во-первых, я веду речь про нагрузочное тестирование.
Для сценарных тестов это самое то и удобное. Одно из лучших API.
Во-вторых, у меня совсем не срослось нагрузочное тестирование в этом API. Если у вас работает и вас устраивают результаты, ваше право.
Думаю, что мы выложим наработки в некотором будущем и можно будет проверить независимо эти выводы.
(31)Может мы немного о разном. Тогда напишу так:
- от 1С ответов на вопросы с клещами и огнем не дождешься, честно меня такое общение напрягает и желания тратить время на подобную переписку все меньше и меньше;
- ссылок нет, но нет и подтверждающих обратное;
- можете запускать столько сессий сколько вам нужно, но мы столкнулись с тем на практике, что при запуске большого количества клиентов с несколькими тест менеджерами система начинает глючить - растет непонятная нагрузка на процессор, некоторые операции с памятью и что-то еще уже не помню.
Возможно вы на это даже не обращали внимание, не с чем сравнить, все равно на такую ситуацию может разные условия в окружении. Для нас при проведении нагрузочного теста - оказалось критично.
В рамках же запуска сценарных тестов - вариантов нет пользуемся и будем пользоваться.
Вот лог переписки с 1С, запрос делали через коллег:
- от 1С ответов на вопросы с клещами и огнем не дождешься, честно меня такое общение напрягает и желания тратить время на подобную переписку все меньше и меньше;
- ссылок нет, но нет и подтверждающих обратное;
- можете запускать столько сессий сколько вам нужно, но мы столкнулись с тем на практике, что при запуске большого количества клиентов с несколькими тест менеджерами система начинает глючить - растет непонятная нагрузка на процессор, некоторые операции с памятью и что-то еще уже не помню.
Возможно вы на это даже не обращали внимание, не с чем сравнить, все равно на такую ситуацию может разные условия в окружении. Для нас при проведении нагрузочного теста - оказалось критично.
В рамках же запуска сценарных тестов - вариантов нет пользуемся и будем пользоваться.
Вот лог переписки с 1С, запрос делали через коллег:
За объяснением относительно аномально нагрузки на сервер приложений при эмуляции работы 10 пользователей обратились в службу поддержки компании «1С».
"От компании «1С» получили официальный ответ, что клиент тестирования и менеджер тестирования не предназначены и не проектировались под использование в нагрузочных тестах."
"От компании «1С» получили официальный ответ, что клиент тестирования и менеджер тестирования не предназначены и не проектировались под использование в нагрузочных тестах."
(13)
1. Так вот откуда взялась эта цифра, что именно 1500+ пользователей будут нажимать 50 клавиш одновременно? Может там активные пользователи и они за единицу времени нажимают 100 клавиш.. А при таком допущении получим двукратный разброс в результатов...
В таком случае тест получается ничем не информативнее чем "Стандартное нагрузочное тестирование" от Вендора. Но там хотя бы есть четкое понимание, как происходит пересчет "стандартных" пользователей в "реальных".. вот в этой статье:
2. Действительно, не хватает подробного описания как время вызова (текущее) превращается в очередь. Также идет подмена понятий, ведь в консоли администрирования кластера 1С есть как колонка "время вызова (текущее)" так и "время вызова сервиса (текущее)" какой именно показатель используется в формуле - вопрос.
1. Так вот откуда взялась эта цифра, что именно 1500+ пользователей будут нажимать 50 клавиш одновременно? Может там активные пользователи и они за единицу времени нажимают 100 клавиш.. А при таком допущении получим двукратный разброс в результатов...
В таком случае тест получается ничем не информативнее чем "Стандартное нагрузочное тестирование" от Вендора. Но там хотя бы есть четкое понимание, как происходит пересчет "стандартных" пользователей в "реальных".. вот в этой статье:
2. Действительно, не хватает подробного описания как время вызова (текущее) превращается в очередь. Также идет подмена понятий, ведь в консоли администрирования кластера 1С есть как колонка "время вызова (текущее)" так и "время вызова сервиса (текущее)" какой именно показатель используется в формуле - вопрос.
(18)
По п.1 Не соглашусь с вами.
По п.2 Добавил информацию. Какой из показателей за что отвечает, я написал. Рекомендую брать первый. Отмечу что, всегда первый больше или равен второму. Подмены понятий нет, прочитайте статью, в которой я описываю что такое показатель очередь и как его считаем.
По п.1 Не соглашусь с вами.
По п.2 Добавил информацию. Какой из показателей за что отвечает, я написал. Рекомендую брать первый. Отмечу что, всегда первый больше или равен второму. Подмены понятий нет, прочитайте статью, в которой я описываю что такое показатель очередь и как его считаем.
(20) Вы поймите, я задаю вопросы не спора ради, а чтобы понять достоверность указанных цифр. На чем они основываются - из статьи не понятно, увы... Ваше слово против моего.. Вы говорите что данная нагрузка характерна для 1500 пользователей, нажимающих 50 клавиш одновременно, а я говорю 50 клавиш одновременно в среднестатистической системе нажимают 3000 пользователей.. кто прав?
(23) Информации много, изложить детально каждый пункт довольно много текста получится. Попробую объяснить:
1. В статье я привожу результаты на примере конкретной системы и конкретной модели. Я не говорю голословно, привожу графики, факты, результаты замеров, обоснования. В данном случае цифры взяты по результатам наблюдений рассматриваемой системы. Если этого не достаточно для достоверности, ну не знаю, что вам еще сказать. Если хотите демонстрацию, пожалуйста в приват, обсудим такой вариант.
2. Делал замеры на разных серверах, к которым имею доступ, общался с коллегами и в разговоре получил информацию, что в других компаниях данная формула справедлива. Исходя из этого я делаю соответствующие выводы. Вы говорите теоретически, проверьте у себя, отпишитесь.
3. Компания, которую я рассматриваю среднестатистический пользователь ERP. По замерам на рабочей базе было установлено (я привожу графики), что для 1000 пользователей количество не нулевых значений в поле время вызова (текущее), в среднем (при работе в пике) каждый срез замера насчитывается 50-55 значений. Ночью, к примеру, этот показатель 2-3. В моменты отчетности или другие пики он может подниматься до 100 (злодей запустить удаление помеченных, завис rphost и т.п.).
50/1000 = 0.05 это 5%.
4. Действительно можно запустить и 10 000 пользователей, но все они ничего не будут делать. Или же запустить как я в тесте 350 пользователей и заставить их в максимально возможном ритме формировать документы. Или же выполнять обработку в потоках по загрузке документов, тогда вообще 12-20 пользователей положат сервер. Мы тут делаем акцент на статистике. На нашем примере, в вашем случае коэффициент может быть другой (об этом я упоминаю в ведении). Будет у вас коэффициент 0.5%, отлично можете при выполнении нагрузочного теста придерживаться его. Но важна цель выполнения, что вы пытаетесь решить: перевод на другую СУБД, оценку мощностей для роста компании, нагрузочное тестирования при разработке, что-то другое?
5. Тест центр мне не нравится, но мой "организм" не принял его. Как и "Сценарное тестирование".
1. В статье я привожу результаты на примере конкретной системы и конкретной модели. Я не говорю голословно, привожу графики, факты, результаты замеров, обоснования. В данном случае цифры взяты по результатам наблюдений рассматриваемой системы. Если этого не достаточно для достоверности, ну не знаю, что вам еще сказать. Если хотите демонстрацию, пожалуйста в приват, обсудим такой вариант.
2. Делал замеры на разных серверах, к которым имею доступ, общался с коллегами и в разговоре получил информацию, что в других компаниях данная формула справедлива. Исходя из этого я делаю соответствующие выводы. Вы говорите теоретически, проверьте у себя, отпишитесь.
3. Компания, которую я рассматриваю среднестатистический пользователь ERP. По замерам на рабочей базе было установлено (я привожу графики), что для 1000 пользователей количество не нулевых значений в поле время вызова (текущее), в среднем (при работе в пике) каждый срез замера насчитывается 50-55 значений. Ночью, к примеру, этот показатель 2-3. В моменты отчетности или другие пики он может подниматься до 100 (злодей запустить удаление помеченных, завис rphost и т.п.).
50/1000 = 0.05 это 5%.
4. Действительно можно запустить и 10 000 пользователей, но все они ничего не будут делать. Или же запустить как я в тесте 350 пользователей и заставить их в максимально возможном ритме формировать документы. Или же выполнять обработку в потоках по загрузке документов, тогда вообще 12-20 пользователей положат сервер. Мы тут делаем акцент на статистике. На нашем примере, в вашем случае коэффициент может быть другой (об этом я упоминаю в ведении). Будет у вас коэффициент 0.5%, отлично можете при выполнении нагрузочного теста придерживаться его. Но важна цель выполнения, что вы пытаетесь решить: перевод на другую СУБД, оценку мощностей для роста компании, нагрузочное тестирования при разработке, что-то другое?
5. Тест центр мне не нравится, но мой "организм" не принял его. Как и "Сценарное тестирование".
(28)
Мы сейчас не рассматриваем денежную составляющую. Только точность расчетов.
Бесплатно можно посмотреть результаты тестирования сферической системы в вакууме на сайте завершенных проектов ЦКТП и примерно рассчитать необходимые ресурсы.
На мой взгляд, изюминка подхода, описанного в статье, как раз и заключается в том, что не нужно тратить большой бюджет на лицензии, а можно протестировать экстремальных пользователей(ботов) и через определенный, не взятый с потолка, коэффициент посчитать эквивалент нагрузки реальных пользователей. Поэтому и пытаюсь раскрыть эту тему в комментариях..
Мы сейчас не рассматриваем денежную составляющую. Только точность расчетов.
Бесплатно можно посмотреть результаты тестирования сферической системы в вакууме на сайте завершенных проектов ЦКТП и примерно рассчитать необходимые ресурсы.
На мой взгляд, изюминка подхода, описанного в статье, как раз и заключается в том, что не нужно тратить большой бюджет на лицензии, а можно протестировать экстремальных пользователей(ботов) и через определенный, не взятый с потолка, коэффициент посчитать эквивалент нагрузки реальных пользователей. Поэтому и пытаюсь раскрыть эту тему в комментариях..
(35) Данный тест был ничуть не бесплатный, а стоил достаточно хорошее количество денег. Даже выполнение всем известного теста Гилева стоит определенных "денег".
Т.е. хотите или нет, но бюджет перед выполнением проекта должен быть. И в зависимости от этого можете отталкиваться что сможете сделать, а что нет.
Т.е. хотите или нет, но бюджет перед выполнением проекта должен быть. И в зависимости от этого можете отталкиваться что сможете сделать, а что нет.
Вопрос только зачем тестировать ERP без производства? Результаты будут ни о чём. Взяли бы уж УТ или хотя бы заголовок статьи не такой кликбейтный. В сценарии тестирования ERP критичен расчёт себестоимости, и на Postgres именно там и будут проблемы, плюс обязательно нужно многопользовательское тестирование во время расчёта себестоимости. К самой методике вопросов нет, расписано хорошо.
(40) Отвечаю на вашу критику:
1. ERP/УТ/КА - это одна и та же конфигурация, не знали?
2. Кто в здравом уме будет запускать расчет себестоимости при максимальной пиковой нагрузке, если только от безнадеги. Я не знаю, как на очень больших базах с ТБ это делают, но мы запускаем только на ночь и на выходных, иначе она даже может не запуститься. По обязательности наличия такого специфического теста я с Вами не соглашусь. Его обычно вставляют в различные проверки из-за того что нужно что-то выбрать и это очень тяжелая операция. Но ни разу не слышал, чтобы одновременно тестировали при этом нагрузку из пользователей.
3. У нас были определенные задачи тестирования, приоритеты, определенные ограничения по времени, во всех этих рамках мы выполнили тест. У вас возможно перекос со стороны производства, соответственно иные приоритеты и рамки и имеет смысл выполнять в комплексе с производством.
4. Чуть позже, думаю что мы выложим готовый инструмент по управлению нагрузкой, и все желающие смогут поиграться у себя. И даже поделиться с сообществом результатами, будет интересно ознакомиться.
1. ERP/УТ/КА - это одна и та же конфигурация, не знали?
2. Кто в здравом уме будет запускать расчет себестоимости при максимальной пиковой нагрузке, если только от безнадеги. Я не знаю, как на очень больших базах с ТБ это делают, но мы запускаем только на ночь и на выходных, иначе она даже может не запуститься. По обязательности наличия такого специфического теста я с Вами не соглашусь. Его обычно вставляют в различные проверки из-за того что нужно что-то выбрать и это очень тяжелая операция. Но ни разу не слышал, чтобы одновременно тестировали при этом нагрузку из пользователей.
3. У нас были определенные задачи тестирования, приоритеты, определенные ограничения по времени, во всех этих рамках мы выполнили тест. У вас возможно перекос со стороны производства, соответственно иные приоритеты и рамки и имеет смысл выполнять в комплексе с производством.
4. Чуть позже, думаю что мы выложим готовый инструмент по управлению нагрузкой, и все желающие смогут поиграться у себя. И даже поделиться с сообществом результатами, будет интересно ознакомиться.
(41) Дело в том, что при использовании Postgres и хорошей детализации учёта ночного времени или даже выходных для расчета может не хватить, и придётся пользователям совмещать рабочее время с расчётом. Я такое уже проходил. Оптимизация и сокращение времени расчета может занять длительное время, а также имеет свойство резко меняться после очередного обновлениях конфигурации или платформы. Но производство результатов от эксперта ждать не будет, поэтому держать нагрузку система должна. Плюс существуют непрерывные производства или работа в 3 смены, про них тоже мало кто в 1С думает.
(42) Уточню мы проводили тест на определенной целевой базе. Ваша целевая база ваши условия, будет другой сценарий и другой тест.
1. В рассматриваемой базе себестоимость не поехала, просто не поехала вообще не считалась. Мы ее оптимизировали, стала 3-6 часов. В ночь укладывается. Поэтому не критично.
2. Еще раз разные целевые базы - разные сценарии.
1. В рассматриваемой базе себестоимость не поехала, просто не поехала вообще не считалась. Мы ее оптимизировали, стала 3-6 часов. В ночь укладывается. Поэтому не критично.
2. Еще раз разные целевые базы - разные сценарии.
Отличная статья. Спасибо.
Возникло пару вопросов:
1. Почему тестирование проводили на платформе 8.3.16? На конец 2021 года (насколько я понял именно тогда и проводилось данное тестирование) это уже была достаточно старенькая платформа.
2. Вы могли бы сделать такие же тесты на, например, 21й платформе? Было бы интересно посмотреть как поменялась производительность в разрезе сервера 1с (многие пишут, что от релиза к релизу она падает)
3. Не очень понял какие настройки кластера были сделаны. Как настроены рабочие процессы и какие ограничения для них создавали? По количеству пользователей/по памяти?
Возникло пару вопросов:
1. Почему тестирование проводили на платформе 8.3.16? На конец 2021 года (насколько я понял именно тогда и проводилось данное тестирование) это уже была достаточно старенькая платформа.
2. Вы могли бы сделать такие же тесты на, например, 21й платформе? Было бы интересно посмотреть как поменялась производительность в разрезе сервера 1с (многие пишут, что от релиза к релизу она падает)
3. Не очень понял какие настройки кластера были сделаны. Как настроены рабочие процессы и какие ограничения для них создавали? По количеству пользователей/по памяти?
(44)
1. Может вы удивитесь, но кое-кто сидит еще на 8.2. Т.е. какие входные условия от заказчика пришли, на тех данных и проводили тестирование. Это была реальная практическая задача, а не "just for fan".
2. Это конечно интересно, также здорово посмотреть как меняется производительность на этих платформах для версий PG 11,13,14 и MS SQL. На это требуется время, подготовка, проведение, ресурсы. Для теста нужна конфигурация с достаточным объемом данных, а тут, процедура выгрузки-загрузки базы под 1 ТБ, будет занимать практически сутки.
Как только появится достаточно времени и свободных ресурсов, то попробуем выполнить хотя бы часть. Попробую написать генератор данных для демонстрационной базы, это будет значительно проще, хотя и не так уже объективно.
Что-то падает, что-то лучше становится.
3. Как мы писали выше, то изменили количество соединений на хост от дефолтных - это где-то в 4-6 раз меньше. Для теста мы не ограничивали расход памяти, а управление оставили по производительности. Остальные параметры можно принять дефолтными.
1. Может вы удивитесь, но кое-кто сидит еще на 8.2. Т.е. какие входные условия от заказчика пришли, на тех данных и проводили тестирование. Это была реальная практическая задача, а не "just for fan".
2. Это конечно интересно, также здорово посмотреть как меняется производительность на этих платформах для версий PG 11,13,14 и MS SQL. На это требуется время, подготовка, проведение, ресурсы. Для теста нужна конфигурация с достаточным объемом данных, а тут, процедура выгрузки-загрузки базы под 1 ТБ, будет занимать практически сутки.
Как только появится достаточно времени и свободных ресурсов, то попробуем выполнить хотя бы часть. Попробую написать генератор данных для демонстрационной базы, это будет значительно проще, хотя и не так уже объективно.
Что-то падает, что-то лучше становится.
3. Как мы писали выше, то изменили количество соединений на хост от дефолтных - это где-то в 4-6 раз меньше. Для теста мы не ограничивали расход памяти, а управление оставили по производительности. Остальные параметры можно принять дефолтными.
(45) 1. про релиз платформы теперь понятно. Требование заказчика. Хотя немного странное.
Вроде бы как раз начиная с этого релиза пошли массовые жалобы на платформу. Многие на 8.3.15 остались. Но тех, кто остановился именно на 16й версии по собственной воли не знал до этого момента.
Вроде бы как раз начиная с этого релиза пошли массовые жалобы на платформу. Многие на 8.3.15 остались. Но тех, кто остановился именно на 16й версии по собственной воли не знал до этого момента.
(46) Уже нет, после детального исследования проблем работы этого релиза особенно с PG, то мы собрали силы в кулак и перевели, его на 8.3.19.
И это не самый плохой релиз. Вот к примеру, 8.3.17, пришлось экстренно откатывать обратно (на предыдущую). А так мы делаем очень редко и это после достаточно объемного тестирования и обсуждения с коллегами.
И это не самый плохой релиз. Вот к примеру, 8.3.17, пришлось экстренно откатывать обратно (на предыдущую). А так мы делаем очень редко и это после достаточно объемного тестирования и обсуждения с коллегами.
(51) В ближайшее время планируем выпустить несколько релизов Фреймворка "Тестирование 3.0" (конец октября, ноябрь), в которые должны войти доработки необходимые для выполнения подобного нагрузочного теста. Планировали выпустить раньше, но в связи с обстоятельствами вынуждены перенести сроки. Порядок будет следующий:
1. Сначала релиз обработки для формирования огромного количества цепочек, документов и т.п.. Это требуется для создания из демонстрационной базы пустышки, нормальной базы для нагрузочного тестирования.
2. Релиз менеджера ИИ в рамках фреймворка. Сделаем вторую обучающую статью. Как запустить на демонстрационной базе.
3. По отзывам пользователей, т.е. на основе обратной связи скорректируем планы.
1. Сначала релиз обработки для формирования огромного количества цепочек, документов и т.п.. Это требуется для создания из демонстрационной базы пустышки, нормальной базы для нагрузочного тестирования.
2. Релиз менеджера ИИ в рамках фреймворка. Сделаем вторую обучающую статью. Как запустить на демонстрационной базе.
3. По отзывам пользователей, т.е. на основе обратной связи скорректируем планы.
Статья отличная!
1) В статье к сожалению ничего не нашел про дисковую подсистему стендов и характеристиках канала связи между серверами 1С и SQL. Можно узнать поподробнее?
2) Есть у вас информация (может быть в других ваших статьях) о степени влиянии на производительность при размещении связки 1С и SQL на одной машине и раздельно?
1) В статье к сожалению ничего не нашел про дисковую подсистему стендов и характеристиках канала связи между серверами 1С и SQL. Можно узнать поподробнее?
2) Есть у вас информация (может быть в других ваших статьях) о степени влиянии на производительность при размещении связки 1С и SQL на одной машине и раздельно?
(54) Владимир, спасибо за оперативный ответ.
1. temp в VRAM - сервер 1С, верно?
2. "Для больших только раздельно." - применительно к ERP большие базы это скольков попугаях пользователей всего/из них активных (в среднем)? Например если оперативы 200Gb на сервер.
1. temp в VRAM - сервер 1С, верно?
2. "Для больших только раздельно." - применительно к ERP большие базы это сколько
(55)
1. temp VRAM для СУБД Postgres. Сам Postgres очень любит работать с большим количеством файлов, а 1С любит временные таблицы.
2. Уже большой базой можно считать количество пользователей от 400-500 онлайн, но как заметил Вячеслав, то конечно же зависит на сколько они там активно работают. Есть такой показатель - количество одновременных обращений к сервисам 1С, я про него писал ранее.
3. Критерий среднее количество на мой взгляд не корректно. Вот в рассматриваемой базе, днем пик в 10 часов 1000+, в 2 часа ночи 100. Средняя получается ~500. Но сервер рассчитанный на нагрузку в 500-600 пользователей, просто будет лежать в часы пик.
1. temp VRAM для СУБД Postgres. Сам Postgres очень любит работать с большим количеством файлов, а 1С любит временные таблицы.
2. Уже большой базой можно считать количество пользователей от 400-500 онлайн, но как заметил Вячеслав, то конечно же зависит на сколько они там активно работают. Есть такой показатель - количество одновременных обращений к сервисам 1С, я про него писал ранее.
3. Критерий среднее количество на мой взгляд не корректно. Вот в рассматриваемой базе, днем пик в 10 часов 1000+, в 2 часа ночи 100. Средняя получается ~500. Но сервер рассчитанный на нагрузку в 500-600 пользователей, просто будет лежать в часы пик.
Вакансии
Консультант-программист по информационным системам 1С
Москва
зарплата от 150 000 руб. до 200 000 руб.
Полный день
Москва
зарплата от 150 000 руб. до 200 000 руб.
Полный день