Время как для локальной машины, так и для всей сети кажется немного медленным для такого количества данных. Конечно, это также зависит от того, какая обработка данных выполняется и выполняется ли она синхронно или асинхронно. Например, замедление, когда несколько запросов отправляются подряд, можно объяснить асинхронной обработкой данных. Если данные извлекаются из запроса и помещаются в очередь для «обработки» и ответ немедленно отправляется, то это может быть относительно быстро. Если последующие запросы должны блокироваться во время обработки очереди перед возвратом, это может объяснить замедление. Но сейчас я просто размышляю.
Скорость запроса по сети, очевидно, зависит от физического расстояния, количества прыжков и т. Д. Но цифры, по-видимому, указывают, что в целом он медленнее, чем должен быть. И наиболее вероятная причина состоит в том, что логика в коде не верна ... но без дополнительной информации нелегко угадать причины (по крайней мере, для меня).
Из любопытства я просто выполнил несколько быстрых тестов, которые отправляли сообщения через сокеты на моем локальном компьютере, причем каждый запрос был 10 КБ (пакет ответа намного меньше). Среднее время приема-передачи составило всего 0,22 мс. Аналогичный тест для сервера в двух прыжках в сети в среднем составлял 1,9 мс за один прием. Это было с использованием TCP / IP. При использовании UDP к серверу через два прыжка время составляло в среднем 1,7 мс.
Так что скорости, которые вы видите, кажутся довольно медленными (но аппаратная и сетевая скорость моего теста, возможно, не имеет ничего общего с вашей настройкой ... поэтому эти цифры вам лишь незначительно полезны).
Более ценно, однако, вы можете использовать ping, чтобы получить базовый показатель того, как долго вы ожидаете, что это займет. Вы можете указать размер пакета для ping (опция -s или, возможно, -l в зависимости от используемой версии). Проверка связи с теми же двумя машинами, на которых я запускал другой тест, подтвердила, что время имело смысл.