Время отклика одного из моих серверов в среднем составляет 566 мс, по данным Pingdom (pingdom.com).
Это хороший результат? Стоит ли мне делать больше для его оптимизации?
Трудно сказать, не увидев трассировки между системами. Кроме того, конечно, если используются коммутируемые ссылки, это также может быть разумным.
Сказав это, 566 мс - это довольно много. Я получаю 510 мс по моей шведской ADSL-ссылке на типичный китайский сайт, поэтому, если ваш сайт является хорошо подключенным сайтом в центре обработки данных на Западе, вам, вероятно, следует ожидать меньшего. Например, от шведского центра обработки данных до хоста Amazon E2 на восточном побережье США я получаю менее 100 мс.
Это очень общий вопрос, и ответ зависит от обстоятельств. Если ваш сервер подключен через спутниковую связь, то 566 мс - это хорошо. Если ваш сервер находится в быстром (например, 100 Мбит) соединении (или размещен), то 566 мс - это плохо.
Чтобы быть полезным, вы должны запустить traceroute (или tracert в Windows) и опубликовать результат. Вы также можете использовать Visual Route (www.visualroute.com).
Все зависит от вашей ситуации. Вы используете акустический соединитель со скоростью 9600 бод на телефоне-автомате в Папуа-Новой Гвинее? В таком случае это фантастика. Вы используете OC48, напрямую подключенный к оптоволоконной магистрали AT&T? Тогда это ужасно. Какая связь? Вы используете такие вещи, как видео / передача голоса по IP? Что-нибудь тяжелое для UDP? Если это так, вы столкнетесь с проблемами при такой задержке. Это сработает, только прикосновение неприятно.
Если приложения или пользователи чувствительны к высокой задержке, нет. Имейте в виду, что задержка и пропускная способность - это не одно и то же. Соединение с высокой задержкой может иметь высокую пропускную способность. Время отклика - задержка - это показатель задержки, а не пропускной способности.