Как я могу определить, подходит ли среднее время отклика 566 мс для моего сервера?

Трудно сказать, не видя трассировку между системами. Также, конечно, если задействованы коммутируемые каналы, это также может быть разумным.

Сказав это, 566мс является своего рода большим. Я получаю 510 мс по моей шведской ADSL-ссылке на типичный китайский сайт, поэтому, если ваш сайт является хорошо связанным сайтом в дата-центре на Западе, вам, вероятно, стоит ожидать меньше. Например, от шведского дата-центра до хоста Amazon E2 на восточном побережье США я получаю менее 100 мс.

This is a very generic question, and the answer depends on the circumstances. If your server is connected via a satellite link, then 566ms are good. If your server is on a fast (eg 100MBit) connection (or hosted), then 566ms is bad.

Чтобы быть полезным, вы должны запустить traceroute (или tracert в Windows) и опубликовать вывод. Вы также можете использовать Visual Route (www.visualroute.com).

Это все сводится к вашей ситуации. Используете ли вы акустическую связь 9600 бод на таксофоне в Папуа-Новой Гвинее? В таком случае это фантастика. Используете ли вы OC48, напрямую подключенный к волоконно-оптической магистрали AT&T? Тогда это ужасно. Что за связь? Вы используете такие вещи, как видео / голос поверх IP? Что-нибудь тяжелое UDP? Если это так, вы столкнетесь с проблемами в это время ожидания. Это будет работать, это будет неприятно.

Если приложения или пользователи чувствительны к высокой задержке, нет. Имейте в виду, что задержка и пропускная способность не совпадают. Соединение с высокой задержкой может иметь высокую пропускную способность. Время отклика - задержка - это измерение задержки, а не пропускной способности.