Обнаружение, что вызывает задержку между вводом доменного имени и загрузкой страницы
Даже если Вы произведете на стороне, то Вам, вероятно, будет нужен человек к связи между пользователями и третьей стороной.
Я думал бы о гибридной модели. Получите человека более низкого уровня, который может сделать работу светового сигнала IT, сбросы пароля, заторы принтера, отключили сетевые кабели, и т.д., и медицинскую сортировку заготовки по проблемам IT, поскольку они входят. Затем посмотрите на произведение на стороне для "тяжелого подъема": Установки Сервера, сетевая инфраструктура maintainence, и т.д.
Мы являемся несколько более крупными, чем Вы, но нам везло с компанией под названием все-Покрытый.
Во-первых, получите высокоуровневое представление того, что происходит, когда страница загружается с помощью расширения Firebug для Forefox. Я покажу Вам точное количество времени, которое каждый компонент веб-страницы занимает для загрузки. Это даст Вам первый ключ к разгадке для того, что точно необходимо исследовать.
Если это - действительно проблема DNS, один из самых мощных инструментов к отладке DNS dig. С +trace опция, это покажет Вам, все посреднические шаги должны были искать домен с временами поиска для каждого шага.
Если это - проблема с установлением соединения TCP к веб-сайту, можно сначала попытаться просто ping это. Если круговая задержка является большой, можно хотеть попробовать tcptraceroute на порте 80, который использует пакеты TCP вместо UDP (или ICMP) как значение по умолчанию traceroute для наблюдения, где пакеты отложены. Используя TCP воспроизвел бы более искренне обработку, Ваши пакеты входят в посреднические сети, некоторые поставщики могут отрегулировать трафик UDP (и полностью отфильтровать ICMP - или на самом деле дать ему высокий приоритет, и затем Вы не видите, что TCP медленнее).
Если время разрешения DNS коротко, и RTT к серверу также, он может иметь полные проблемы...
Прежде, чем вырыть в сети и пакетный сниффинг и все это, удостоверьтесь, что это не конкретный браузер, установите новую копию Chrome и посмотрите, как это делает. Затем удостоверьтесь, что это не конкретная машина, попробуйте его на других машинах в той же сети. Затем удостоверьтесь, что это не конкретная сеть, попробуйте его из кафе Wi-Fi или дома друга.
Если это все еще медленно, у профессора Moriarty и Willam есть некоторые великолепные места для рытья глубже. Действительно ли это - большая страница с длинной ТАБЛИЦЕЙ? Плагин? IFRAMES? Много JavaScript?
Необходимо посмотреть на синхронизацию различных сетевых пакетов назад и вперед между компьютером, сервером DNS и веб-хостом (хостами). При использовании прокси-сервера необходимо проверить тот трафик.
Действительно хорошим инструментом для этого является Wireshark.
Сравните время между поиском DNS, ответом, веб-сервер (HTTP) запрос, и ответом веб-сервера. Типичная веб-страница будет иметь много отдельных частей, каждая из которых является запросом от Вашего компьютера и ответа сервером. Проверьте ту же страницу от другого компьютера/сети для наблюдения различий. Не забудьте очищать свой DNS и кэши браузера перед тестированием.
Действительно, что заставляет Вас думать, что это - связанный DNS?
Необходимо ответить себе следующие вопросы:
- Какова аппаратная производительность? У Вас есть аппаратные узкие места (т.е. плохая производительность HDD)?
- Действительно ли Ваша апачская конфигурация оптимальна? Посмотрите, что клиенты Max, запросы на ребенка, поддерживают.
- Код php/etc. оптимизирован?
Сравните своей апачской конфигурации с помощью ab.
Следите за аппаратным использованием (CPU, HDD).
Если это имеет место, пойдите с подсистемами балансировки нагрузки (HAproxy) и используйте несколько веб-серверов.
Скажите нам доменное имя, затем мы можем протестировать, как быстро авторитетный DNS. Здесь существует два фактора:
- географическое положение сервера DNS, который влияет на сетевую задержку
- время отклика сервера
Большинство авторитетных серверов должно смочь отдать ответ в нескольких миллисекундах, таким образом, во многих случаях сетевая задержка будет более важной, чем мощность сервера DNS.
Если сам сервер DNS будет хорошо подключен затем, то это будет до не только, как быстро веб-сервер, но также и на макете страницы.
Некоторые методы макета (конкретные таблицы, ISTR) вызывают трудности для браузеров, потому что они препятствуют тому, чтобы браузер представил страницу, пока большая часть содержания не была загружена.
Предложение @Moriarty расширения Firebug является хорошим для рассмотрения DNS и Запросов HTTP, но я не думаю, что это решит потенциальную проблему плохого макета страницы.