Определение вкладчиков по истекшему времени во время сетевого запроса

245
Aaron Johnson

Ситуация:

  • Есть удаленный сервер.
  • Я запускаю клиентскую программу, которая звонит на сервер и запрашивает данные.
  • Эти запросы выполняются очень медленно.
  • Сервер ограничивает количество результатов до 50, а остальное разбивает на страницы. Таким образом, если есть 300 общих результатов, я должен сделать в общей сложности 6 отдельных запросов.
  • (За комментарий Джеймса) Данные представлены в текстовом формате JSON.
  • (Согласно другому комментарию Джеймса) Соединение является соединением https (SSL).

Владелец сервера предложил увеличить количество результатов на странице, чтобы я мог делать меньше запросов.

Хотя я думаю, что это поможет, я беспокоюсь, что сделка не будет достаточно быстрой для моих целей. Интересно: а что если проблема не в издержках сервера при получении данных? Что, если наибольшее снижение производительности связано с пропускной способностью сети и задержкой?

Как бы я это выяснил? У меня нет доступа к серверу вообще. Допустим, запрос занимает 3 секунды. Затем:

  1. Какая часть этих 3 секунд тратится на открытие TCP-соединения?
  2. Какая часть расходуется на отправку данных запроса?
  3. Какая часть тратится на ожидание получения данных сервером?
  4. Какая часть расходуется на ожидание получения всех запрошенных данных на моем компьютере?

Я на самом деле не хочу, чтобы мне пришлось свернуть свой собственный код TCP / IP, чтобы получить низкоуровневый доступ, необходимый для измерения подобных вещей.

Я уверен, что для этого должны быть написаны инструменты. В поисках Google я вижу такие программы, как netstat, ss, netperf, ttcp и т. Д. Но я даже не уверен, какие слова использовать в поиске Google для поиска решений этой проблемы.

Есть идеи?

0
Предположим, это зависит от того, какие данные вы запрашиваете - если вы возвращаете текст json, то, вероятно, не ограничение полосы пропускания и больше ограничений обработки на стороне сервера. Хотя это может быть неполное решение, что-то вроде Wireshark (http://www.wireshark.org/) поможет вам отслеживать сетевой трафик и регистрировать пакеты по порядку. Затем вы можете сравнить временные метки на них, чтобы увидеть, какая часть процесса занимает больше всего времени? James 10 лет назад 1
Это возвращает текст JSON. Я обновлю пост, чтобы отразить это. Захват пакетов в Wireshark - хорошая идея. Я попробую. Aaron Johnson 10 лет назад 0
О, и я бы также добавил, что согласование SSL-рукопожатия, несомненно, вызовет накладные расходы с каждым запросом. Вы не указываете, является ли это http: // или https: // James 10 лет назад 0
Хорошая точка зрения. HTTPS. Я обновлю вопрос, чтобы отразить это также. Aaron Johnson 10 лет назад 0
В этом случае сокращение количества запросов и увеличение набора результатов для каждого из них может оказать существенное влияние James 10 лет назад 0
Я думаю, что ваша проблема, скорее всего, связана с запросом или с тем, как вы обрабатываете набор результатов (выполняя это на стороне клиента, а не позволяя БД выполнять свою работу). сколько времени занимает выполнение вашего запроса, если вы вызываете его из консоли управления БД, в то время как он удален на сервер? если ваш сайт не находится под значительной нагрузкой, такие факторы, как время создания соединения, подача данных на провод, согласование https и т. д., незначительны, и если вы правильно составляете и выполняете свои запросы, многие маленькие соединения должны быть быстрее, чем одно большое. ваша задержка почти наверняка в ожидании ответа. Frank Thomas 10 лет назад 0
Аарон: Что касается вашего комментария к SO: Публикация одного и того же вопроса сразу на нескольких сайтах Stack Exchange противоречит правилам. Если вы считаете, что начали не с того сайта, вы можете * пометить * свой вопрос и попросить модератора перенести его на другой сайт. Иногда вы также можете * удалить * свой вопрос на одном сайте и опубликовать его снова на другом. Миграция, вероятно, является более хорошим решением, особенно если уже есть ответы или комментарии. Если вам нужен этот вопрос о переполнении стека (* вместо * Super User), дайте мне знать. Daniel Beck 10 лет назад 0
Даниэль: Спасибо за информативный комментарий и хорошую информацию здесь. Я не заметил ссылку, которую вы вставили в свой оригинальный комментарий в SO, и не читал ее до сегодняшнего утра. В настоящее время я не получил ответов на SO. Эндрю закрыл вопрос, но он также может быть просто удален. Спасибо за вашу помощь. Aaron Johnson 10 лет назад 0

0 ответов на вопрос

Похожие вопросы