Рекомендации по тайм-ауту веб-службы

Возьмите объем данных, которые вы передаете через веб-службу, и посмотрите, сколько времени займет этот процесс.

Добавьте к этому числу 60 секунд и проверьте.

Если вы можете добиться таймаута при хорошем соединении, добавьте еще 30 секунд.

промыть и повторить.

Этот вопрос и те, на которые есть ссылки в ответах на него, могут помочь: Существует ли какой-либо отраслевой стандарт неприемлемого времени отклика веб-приложений?

Немного не соответствует вашему вопросу (без временных интервалов, извините), но я подозреваю, что это полезно для вашей работы: Распространенный подход к тайм-аутам - уравновесить их таймерами "отката". Это выглядит примерно так: В первый раз, когда истекает срок службы, не беспокойтесь об этом. Второй раз подряд время ожидания услуги истекает, не вызывайте его в течение N секунд. В третий раз подряд время ожидания услуги истекает, не вызывайте его в течение N + 1 секунды. Затем N + 2, N + 3, N + 5, N + 8 и т. д., Пока вы не достигнете некоторого максимального предела M.

Счетчик тайм-аута сбрасывается, когда вы получаете правильный ответ.

Я использую последовательность Фиббоначи, чтобы увеличить период времени «отката», но, конечно, вы можете использовать любую другую подходящую функцию - суть в том, что если услуга, которую вы пытаетесь, продолжает отсчитывать вас, вы «верите» в нее. становится все меньше и меньше, поэтому вы тратите меньше ресурсов, пытаясь добраться до него, и реже стучитесь в дверь. Это может помочь службе на другом конце, которая может быть просто перегружена, а повторный запрос только усугубит ситуацию, и это увеличит ваше время ответа, так как вы не будете ждать службу, которая вряд ли ответит.

Обычно мы берем ожидаемое время ответа для этой веб-службы (как указано в нашей спецификации интерфейса) и добавляем к нему 30 секунд.

Затем мы отслеживаем журналы во время UAT, чтобы увидеть, есть ли какие-либо закономерности (например, определенные вызовы БД, занимающие много времени), и при необходимости изменяем.

Эти сведения о 30+ секундных тайм-аутах - нелепый совет, ИМО. Ваши таймауты должны составлять около 3 секунд. да. Три. Число после двух и до четырех. Если вы создаете приложение на основе SOA, то ОПРЕДЕЛЕННО 3 секунды или меньше.

Подумайте об этом ... пользователь вашего приложения ожидает ВСЕГО времени ответа около пяти секунд или меньше (желательно около трех). Если КАЖДЫЙ ИНДИВИДУАЛЬНЫЙ ЗВОНОК ОБСЛУЖИВАНИЯ требует более пары * миллисекунд *, значит, вы попали в беду. Ожидание возврата ОДНОЙ услуги более 30 секунд - это вечность. Пользователь никогда не будет ждать так долго. Кроме того, если вы знаете, что они должны возвращаться в диапазоне менее одной секунды, какой смысл ждать еще одного 30 или более секунд, чтобы сигнализировать об ошибке; он не будет волшебным образом работать там, где это не было 28 секунд назад. Если ваше приложение имеет резкие колебания среднего времени отклика от менее одной секунды до более 30 секунд, что-то было спроектировано неправильно. Вы можете подумать о каком-то кешировании или о чем-то подобном.