Как я могу измерить разбивку сетевого времени, проведенного в iOS?

Question

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

В качестве примера, вот несколько этапов, через которые проходит запрос:

1. Исходное радиосвязь (значительный источник задержки в EDGE)
2. Поиск DNS (если не кэширован)
3. Подтверждение SSL / TLS.
4. Загрузка HTTP-запроса, включая данные.
5. Время обработки сервером.
6. Загрузка ответа HTTP.

Я могу решить большинство из них (например, включив радиоранее через фиктивный запрос, установление фиктивного соединения HTTP 1.1 и т. д.), но я хотел бы знать, какие из них на самом деле способствуют медленной работе сети, на реальных устройствах, с моими фактическими данными, с использованием реальных вышек сотовой связи.

Если бы я использовал WiFi, я мог бы отследить их с помощью Wireshark и некоторых синхронизированных часов, но мне нужны сотовые данные.

Есть ли какой-нибудь хороший способ получить этот подробный анализ, кроме необходимости(Гак!) использовать веВы можете использовать низкоуровневый сокет для воспроизведения моего ванильного http-запроса?

Answer 1

Простым решением этой проблемы может быть, как только приложение будет запущено, установить соединение Long Polling с сервером (вы можете выбрать, когда необходимо установить это соединение, а когда отключить), но это своего рода Хак, если вы хотите, чтобы избежать всех прослушиваний пакетов с меньшим количеством API-интерфейсов, которые предоставляет iOS.

Answer 2

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

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

Затем я строю график временной шкалы.(Инструмент был бы неплох, но я сделал это вручную.) Я ищу такие вещи, как 1) сообщения, повторно переданные из-за тайм-аутов, 2) задержки между временем получения сообщения и временем, в которое оно было обработано.

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

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

Существует тенденция оставлять вопросы о производительности в поисках волшебных исправлений для улучшения ситуации.Но настоящее волшебное исправление состоит в том, чтобы усовершенствовать вашу диагностическую технику, чтобы она указала вам, что нужно исправить, потому что она будет отличаться от чьей-либо еще.