Связь ping с воспринимаемым ответом графического интерфейса браузера
Мы периодически получаем жалобы на плохой отклик графического интерфейса (страницы браузера), которые нам необходимо изучить. Я ищу быструю и дешевую первую проверку, чтобы узнать, не связана ли проблема с задержкой в сети или производительностью сервера. Кто-нибудь сталкивался с обсуждением времени пинга и воспринимаемого ответа GUI? Я понимаю, что ответ GUI сложен, но было бы неплохо, если бы мы могли найти или разработать практическое правило типа «Хмммм, пинг больше 200, это могут быть проблемы с сетью». В идеале это находится в сценарии на машине пользователя, чтобы мы могли видеть задержку, которую они видят ... (BASH, Linux). Ссылка на хорошую страницу обсуждения была бы прекрасным ответом, как и любая рекомендация другого исходного материала.
10/3: Спасибо за все предложения. Хотя они полезны, и я буду их исследовать, главное, что я искал в этом запросе, - это быстрый и грязный взгляд на порядок. Например, я предполагаю, что если время пинга составляет 1 мс, хотя и не является окончательным, это может означать, что задержка в сети не является проблемой, сначала посмотрите на сервер; время пинга более 500 мс предполагает, что я могу смотреть на невиновный сервер, страдающий от проблемной сетевой службы. Быстрота - это скорее акцент, чем точность; где я должен искать в первую очередь. Если мое предположение неверно, мне было бы очень хорошо узнать!
Чтобы начать загрузку страницы, требуется как минимум два полных цикла приема-передачи по сети, и это после того, как выполняется поиск DNS, который иногда может занять даже больше времени. Итак, возьмите время пинга и удвойте его, чтобы узнать, как оно влияет на загрузку страницы.
Инструмент отладки браузера, такой как Firebug или инструменты разработчика Chrome, скажет вам конкретно, на что было потрачено время при загрузке страницы, что должно дать вам гораздо лучшее представление о том, что замедляет работу. Например, вот мои инструменты разработчика Chrome говорят мне, на что было потрачено время при загрузке домашней страницы Google:
Взгляни на http://newrelic.com. Зарегистрируйте бесплатную учетную запись, и вы получите пробный период Pro, который должен дать вам хорошее представление о том, где находится узелок.
Суть такова: ответ в графическом интерфейсе (или опыте конечного пользователя, известный как оценка Apdex) является результатом нескольких вещей, происходящих между запросом браузера и завершением браузером рендеринга страницы.
Я часто обнаруживал, что такие мелочи, как плохие выражения CSS или наличие слишком большого количества сложных узлов в HTML-документе, приводили к тому, что браузеру требовалось бесконечно обрабатывать страницу. Иногда это глупый внешний javascript, такой как Analytics, в неасинхронном режиме, который блокирует страницу.
Как упомянул Шейн, такие инструменты, как Firebug (Firefox) и Chrome Inspection (щелкните правой кнопкой мыши и проверьте элемент, затем выберите вкладку сети -> нажмите «Обновить»), они могут сказать вам первое место, где находится узкое место.
Если узким местом является приложение, такие инструменты, как Newrelic, могут дать вам трассировку того, какие вызовы в коде медленные и т. Д.
Нижняя известь: В этот процесс вовлечено много вещей, но вы должны пройти процесс устранения и сначала решить более серьезную проблему с производительностью.