Я предполагаю, что вам требуется постоянная скорость вызовов в секунду (то есть, вам нужно 400 звонков в секунду, распределенных равномерно по второму, насколько это возможно).
Вам нужно адаптивные задержки во время теста - если ваш сервер медленно посылает ответы, вам нужно меньше задержки; когда сервер работает быстро, вам требуется дополнительная задержка между вызовами. Вы можете отслеживать время отклика сервера и рассчитывать задержку для текущего вызова, исходя из того, что это возможно как можно ближе к 400 звонкам/секундам. Он все равно будет колебаться, но он будет намного лучше, чем простой жестко закодированный Thread.Sleep
.
Вам нужно иметь в виду, что со многими активными потоками (в зависимости от аппаратных ресурсов) продолжительность сна в потоке также может колебаться. Я не знаю, насколько вы знакомы с нюансами Thread.Sleep
- вы должны прочитать this answer, чтобы понять ограничения, поскольку это может сыграть роль в планировании ваших тестовых вызовов.
Это очень широкий вопрос, но вы должны попытаться использовать адаптивные задержки, когда вы вычисляете задержку, основанную на времени отклика сервера. Это не даст вам абсолютно устойчивой скорости звонка, но это поможет вам приблизиться. – xxbbcc
Вам нужен одинаковый период между звонками? Вы можете выпустить 400 вызовов так быстро, как только сможете, а затем ждать следующей секунды. – werewindle
В соответствии с предложением @xxbbcc: вы можете попытаться сохранить ** оконную ** скользящую среднюю время в оба конца и использовать текущее среднее значение для оценки вашей задержки. Чтобы запланировать ваши звонки, вместо спящих и связанных с ними неточностей, вы можете захотеть заняться циклом ожидания занятости. Реализация калькулятора скользящих средних окон можно найти здесь: http://stackoverflow.com/questions/29265626/calculate-a-moving-standard-deviation/29269137#29269137 – Alex