mazzyВот как?А як еще?

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

mazzyПропущу всю спорность данного утверждения. Читайте мануалы.Читал, чего и вам советую.

mazzyА для проверки остатков и резервов SELECt нужен?
Он тоже не зависит "ни от размера кэша сервера ни от размера базы"?Я же сказал, подавляющее время. Проверка остатков тоже время занимает, но относительно мало. У всех производителей есть специальные структуры для быстрого получения текущих остатков и оно практически не зависит от размера базы.

mazzy vogenut mazzyЯ правильно понимаю, что 1С не учитывает влияние блокировок в своих тестах, потому что их влияние непредсказуемо? Я совершенно точно уловил вашу мысль?Абсолютно не точно. Я говорю про всех производителей. Ссылки я уже приводил, не поленитеть прочитать.
Тогда:
Либо ваше утверждение ложно.
Либо 1С не производитель.

С вашего разрешения, ваши реплики я буду игнорировать.
Спасибо.Конечно можете игнорировать, ваше право. Напишу для тех, кто возможно тоже не понял почему влияние блокировок непредсказуемо в тестах, и почему производители их не используют. Итак:

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

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

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

Исходя из этих причин, производители обычно настраивают базы так, что-бы во время тестирования блокирования по данным не возникало. Для 1С и Модератор: оффтопик удален. создавайте новые ветки это сделанно просто, т.е. вообще исключена вероятность параллельного создания документов по одному и тому же товару. Что естественно указано в методиках тестирования.

Модератор: оффтопик удален. создавайте новые ветки

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