В связи с постоянным редактированием модератором моих постов, выкладываю здесь свои размышления по поводу тестирования ERP систем производителями. Тема навеяна веткой " Исследование масштабируемости и производительности 1С:Предприятия 8.1 ". Если кому интересно, давайте обсудим. Итак, вопрос стоит стоит, стоит ли использовать блокировки по данным при тестировании ERP систем?

Для начала определимся что такое блокировка? В тестах на производительность, аналогичных 1С, SAP и Microsoft, возникает ситуация, когда создание и проведение документа (в нашем случае Sales and Distribution или по русски РеализацияТоваровУслуг) может приводить к блокировкам по данным, т.е. в упрощенном варианте, в то время когда один документ что-то пишет в некую таблицу по какому-нибудь товару, другой документ, записывающий по тому-же товару в это-же время, будет ожидать окончания транзакции первого. Какие выводы можно сделать из этого, так сказать постулата?

1. Максимальное время ожидания второго документа будет равно времени работы транзакции первого. Это означает, что первый документ в своей транзакции в начале может записать в проблемную таблицу данные, а потом уже записывать в другие (т.к. в реальных системах при проведении документа данные записываются в несколько таблиц). Таким образом время ожидания второго документа будет лежать в диапазоне от 0 до Вт, где Вт это время выполнения транзакции первого документа.

2. При многопользовательском выполнении теста, возникновения блокировок могут быть, а могут и не быть, даже если проводить по одному товару все документы. Как так, спросите вы? Фокус заключается в том, что в тестах производителей документы вводятся через опеределенные интервалы времени. Тем самым, при удачном распределении времени записи документов между пользователями, блокировки могут и не возникнуть, т.к. одновременно будут записываться документы по разным данным. Однако есть также вероятность, что все пользователи начнут одновременно конкурировать между собою по данным. Причем на тестах с большим числом пользователей данная ситуация очень легко может привести к time-out в ожидании. Например, если time-out блокировки настроен на 20 сек, то для 1000 пользователей, время выполнения транзакции каждого пользователя должно быть как минимум (!) 0,02 сек что-бы исключить данный случай, что согласитесь невозможно для существующих продуктов. При реальном тестирования данные параметры конечно будут плавать, причем чем меньше общее время тестирования тем больше будет разброс в результатах.

Исходя из этих причин, производители обычно настраивают базы так, что-бы во время тестирования блокирования по данным не возникало. Для 1С и SAP это сделанно просто, т.е. вообще исключена вероятность параллельного создания документов по одному и тому же товару. Что естественно указано в методиках тестирования. В случае Microsoft, все как всегда, извините, хитрожопей. Как я указывал в более ранних постах, любезно вырезанных mazzy (mazzy, можете вырезать это опять, только пожалуйста, не трогайте выкладки и расчеты), в тестах Microsft товары выбираются из некого пула. Например, для тестов Dynamics AX 4.0, есть два пула на 1000 и 5000 товаров. Из них выбираются 5 линий документа, 4 из пула в 1000 документов, одна из пула 5000. На первый взгляд выглядит это как некая попытка ввести определенное количество блокировок по данным. Но смущает два факта: почему тест работает на 1000 пользователей и почему каждый пользователь вводит один документ раз в 360 сек. Несложные расчеты показывают, что вероятность одновременной блокировки двумя пользователями получается очень низкой. Тем более это относиться к 3 и более пользователям одновременно пытающихся провести документ по одному товару.

Вот наверно в кратце все, что хотел сказать по блокировкам. Будут вопросы, пишите.

Естественно, свои соображения по тестированию ERP систем приветствуются. В качестве примера, приведу здравую мысль господина iscrafm (ниже его предложение по тестированию):

я бы предложил проверить производительность на другом тесте.
Тест с реального производственного предприятия (короткий цикл производства, пищевая отрасль), на котором работала 1С:
1. Ввод заявок на отгрузку продукции (около 80 заказчиков)
2. Разузлование заявок (4-5 тыс позиций сырья и полуфабрикатов)
3. Резервирование сырья на складах
4. Формирование документов отгрузки по складам и потребителям (500-700 накладных)
Указанные действия выполняются одним пакетом, или процедурой проведения.

mazzyУсловия тестирования должны быть максимально приближены к условиям реальной работы.
Чтобы результаты тестирования можно было применять для оценки производительности или требуемого оборудования в реальной жизни.

Поэтому.
Если система "использует" блокировки в реальной жизни, то и в тесте блокировки должны "использоваться".И каковы же условия реальной работы? У вас есть формальное описание этих условий? Реальных условий столько же сколько и реальных внедрений. И все они отличаются друг от друга.

mazzyvogenut, вы просто не знаете для чего и как проводятся тесты.
пойдите и почитайте. http://www.microsoft.com/dynamics/ax/product/hpbenchmark.mspx По делу есть что нибудь? Или вы думаете, я цифры про пулы товаров с потолка взял?

mazzy vogenut mazzyvogenut, вы просто не знаете для чего и как проводятся тесты.
пойдите и почитайте. http://www.microsoft.com/dynamics/ax/product/hpbenchmark.mspx По делу есть что нибудь? Или вы думаете, я цифры про пулы товаров с потолка взял?
Откуда я знаю откуда вы взяли?
Расскажите.По моему вы документы вообще не читаете. Смотрите http://www.microsoft.com/dynamics/ax/product/hpbenchmark.mspx

asdfghjklНе, ну критика - это хорошо. Ваши предложения?Не допускать в тестах возможности блокировки по исходным данным (товары, материалы и т.п.). Т.к. это приводит к непресказуемым результатам. Тогда можно будет сделать единый тест для всех производителей. Впрочем 1С и SAP так и делают.

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

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

Сергей Васкецов vogenut
На основании Вашего сообщения у меня возникает предположение, что Вы думаете, что блокировки на уровне сервера БД возникают только при одновременном доступе к неразделяемому ресурсу двух и более конкурентных пользователей. Вы правда так считаете?Нет конечно. То, что вы описали, больше к системным объектам синхронизации относится, такие как критические секции. На уровне БД все конечно гораздо сложнее. Поэтому и проблем больше.

mazzyИтак, где в исходном документе есть подтверждающие ваше утвердждение данные?Scenario 2 - Complex Sales Orders

Number Of Users - 1000
Transactions Per Hour Per User - 10
Lines Per Hour Per User - 50

80% of Lines from 1,000 Item Pool
20% of Lines from 5,000 Item Pool

расшифровывать надо?

mazzyА сезон начался как только дали документ в зубы и попросили привести цитаты?
Ок. Сезон, так сезон?Я бы посоветовал поумерить свой хамский тон, иначе я буду просто вас игнорировать

Shuhard...
1 ОК - разделим тесты на бенчмарки и крэш-тесты
2 для сравнительных целей (релизы одного вендора)- устроит, для тендерных(выбор вендора/архитектуры)- нет1. Согласен, это более корректный подход
2. Думаю этот вариант нет смысла рассматривать, т.к. он однопользовательский :)