Бесплатный хостинг: «нестабильная доступность» сайта |
Представляю статью, главная цель которой – определить последовательность действий во время анализа нестабильной загрузки страничек, либо недоступности интернет-сайта для простого пользователя.
Вначале следует исключить из перечня возможных неисправностей легко диагностируемые и наиболее очевидные: проблемы на стороне провайдера или, к примеру, отсутствие аккумулятора в ноутбуке и кабеля в розетке.
Также предлагаю опустить трудно решаемые проблемы и различные неисправности локального интернета, либо самого компьютера, требующие непосредственного вмешательства системного администратора.
Остановимся на том, что проблем с Сетью у нас нет и веб-сайты грузятся нормально, однако наш интернет-ресурс доступен с перебоями или же недоступен совсем.
Бесплатный хостинг: как обнаружить причину плохой доступности?
Traceroute
Интернет — огромное количество магистралей, которые ведут от сервера к серверу. Бывают такие случаи, когда наш сервер функционирует и мы видим остальные сайты, однако путь пакетов от нас к нашему веб-сайту оборван: из-за сбоя роутинга сегментировалась сеть или где-то случился сбой в работе каналов интернет-провайдеров.
Разумеется, в консоли команда Traceroute покажет, доступен ли сервер нашего веб-ресурса, через какие сервера пакеты идут и на каком именно месте они «стопорятся». Если ping и traceroute не доходят до нашего сервера, однако достигают сети хостинг провайдера, время звонить в техническую поддержку хостинга или системным администраторам, поскольку.
Когда Traceroute «залипает» где-нибудь на магистральных каналах по дороге к веб-сайту, лучше в обязательном порядке проверить, как виден сайт/сервер с прочих серверов Сети вне вашего провайдера. Вероятно они используют иные магистрали и часто бывает видно, что Traceroute через иные каналы удачно проходит к вашему серверу.
Если все хорошо, то проблемы или у вашего провайдера, или у его провайдеров выше уровнем.
Теперь уже можно позвонить в техническую поддержку локального провайдера и узнать: «какие там лежат магистральные каналы?»
Mtr
Стабильность и скорость интернет-канала — стабильность и скорость самого плохого и медленного канала связи по пути от вас к серверу. Узнать, есть ли какие-либо проблемы с потерями пакетов данных «по пути», большие задержки пакетов данных между различными провайдерами или же между вами и провайдером, можно при помощи небольшой утилиты Mtr.
Mtr – это что-то типа совмещенных Ping и Traceroute. Однако имейте в виду, что это приложение съедает довольно много трафика.
Пример вызова:
mtr -s 1500 --report вашсайт.com
Запрос проверки к веб-порталу yahoo.com:
Показательным будет для нас значение общего процента потерь пакетов нашего, последнего в списке, сервера. Потери на промежуточных серверах, в случае если они не сказываются на последнем, скорее всего, возникают из-за ограничения числа тестовых пакетов к ним.
Как правило, если есть 30-50 % потерь крупных пакетов, то проблемы с подключением становятся ощутимыми, и чем больше процент, тем труднее пробиться.
Проблемы могут возникать на каком-нибудь промежуточном узле. Вдобавок, причиной могут быть проблемы в связи или роутинге пакетов между различными провайдерами.
Иногда провайдером может быть полностью отключена или же ограничена возможность прохождения данных тестовых пакетов (так называемого ICMP-траффика). В таком случае, эти тесты проблему определить не помогут.
Chrome Developer Tools
Если вышеперечисленные тесты проблем не обнаружили, а вы выбрали бесплатный хостинг в Украине, то используем главный удобный и наглядный инструмент под названием Chrome Developer Tools (Firefox Develper Tools, Web Inspector в Safari):
При работе с инструментом Chrome Developer Tools (путь: Menu — Tools — Developer Tools), в пункте «Сеть» (Network), обновляем страничку нашего веб-ресурса и получаем отчет о том, как грузятся на ней все ресурсы:
При удачной загрузке странички ресурса будет видно: когда загрузится весь основной контент странички и она начнет медленно формироваться для показа, когда на сайте начнут работать все вложенные JAVA-скрипты, которые завязаны на работу с компонентами странички и ожидающие полной догрузки главного кода и всех необходимых дополнительных неопределенных вложенных элементов.
Данный момент на изображении выше: вертикальная синяя линия – событие DOMContentLoaded, а вертикальная красная линия – срабатывание Windows.onLoad event.
При помощи данного информационного инструмента можно проверить, все ли в порядке с загрузкой главного содержимого странички и основного html-кода. То есть удостовериться в том, что наш сервер живой и основной движок веб-ресурса не тормозит.
Это первый в перечне элемент. Кликнув по нему, можно получить более подробное время ответа сервера:
Как мы здесь видим, наш веб-браузер ждал от сервера данные 68 миллисекунд и еще 2 миллисекунды она принималась.
Уже по данной информации можно иногда увидеть, что проблема в медленной загрузке веб-сайта — это, к примеру, не миллисекундное, а уже 30-тисекундное формирование главного кода странички.
Это бывает, если перегружен запросами провайдер или сервер, применяется неэффективный код или есть какие-то иные причины, которые впору уже анализировать системным админам и программистам движка.
Ниже в перечне-графике загрузок видно, какие ресурсы на страничке загружаются дольше, что блокирует ее показ, каких ресурсов странички дожидается веб-браузер прежде чем показать страничку.
Весьма частая причина блокировок — зависимость момента начала работы изменяющих или формирующих содержимое странички скриптов от каких-то внешних сервисов сбора статистики, страниц обмена ссылками или рекламных движков.
Данные системы находятся на чужих серверах и часто недоступны нашим системным администраторам, поэтому могут себя вести как угодно, к примеру:
Таким образом, пока не подгрузится, не отработает блок, который ссылается в свою очередь на внешний ресурс, веб-браузер будет от него ожидать результатов, как правило, не отображая содержимое странички или отображая его неправильно, хотя сегодняшние движки веб-браузеров могут работать на опережение.
На скриншоте чуть выше работа скриптов на страничке началась с задержкой в 135 мс в связи с загрузкой рекламного скрипта admobi.js. Бывает, что когда сервер раздачи кода статистики и рекламы доступен, правда отвечает медленно, а веб-браузер, удачно с ним соединившись, ждать отклика может десятки секунд.
Внешние серверы
Как и с Traceroute, данные по загрузке странички через Developer Tools можно и надо проверить «свежим взглядом на собственный сервер» при помощи внешних сервисов-анализаторов, к примеру:
http://www.uptrends.com/aspx/free-html-site-page-load-check-tool.aspx
Это выглядит:
и http://tools.pingdom.com/fpt/
Обратите ваше внимание на конец таблицы первого сервиса с временными результатами. И на начало таблички второго, с ранжированием «как ваш веб-ресурс доступен по скорости, по сравнению с прочими интернет-ресурсами сети», а также числом запросов, временем и объемом загрузки полностью всей странички.
Подобные отчеты, сравнения с таймлайнами загрузки в своем веб-браузере покажут те места, где загрузка веб-ресурса через вашего провайдера несколько отличается от загрузки в данных двух сервисах и где есть наибольшая задержка.
Еще одна «фишка» вышеописанных двух сервисов – возможность выбрать сервер, откуда будет выполняться пробный запрос, то есть сымитировать то, как ваша страничка грузится с сервера в Москве, Берлине или Нью-Йорке.
Странные и редкие «залипания»
- Трудности с работой расширений:
Все отключите и сравните, либо наоборот, включите плагины ghostery и adblock. - Первый контакт с сервером после любого перерыва.
Инициация SSL-сессии для веб-браузера происходит обычно медленней из-за начального обмена ключами, а также проверки сертификатов. Это случается как раз при заходе на интернет-сайт после перерыва, либо очистки кэшей. - Проблемы с получением ключей или сертификатов при загрузке чужих скриптов и элементов странички, которые способны блокировать отображение: рекламные сети, сборщики статистики, баннерообменки.
- Все элементы из прошлого пункта, когда связь с нашим сервером нормальная, но с сервером, который отдает данный встраиваемый элемент — довольно плохая или же он перегружен.
Пока скрипт не догрузится, то может «залипать» рендер странички, OnDom/OnLoad отрабатываются с определенной задержкой. Бывает также, что при просмотре других страничек данный элемент уже полностью кэширован. Здесь можно исключить запросы на такие внешние сервера при помощи внесения на локальном ПК на время в файле hosts по очереди.
Сервер-для-сбора-статистики.ru 127.0.0.1; рекламный-сервер.com 127.0.0.1; прочие сервера. Следует помнить о том, что если мы перенаправляем все запросы вместо каких-нибудь серверов в Сети вовнутрь собственной сети «прямо на ноутбук», мы можем получить небольшую секундную задержку. - Если страничку отдает не один, а сразу несколько серверов по очереди во время распределения нагрузки, бывает, что мы спустя некоторое число раз попадаем на медленный сервер, а затем опять на быстрые.
Здесь можно легко проверить, есть ли отдельное название сервера из тех, куда распределяется нагрузка, и работать уже напрямую. - Сложности с серверами отдачи статики, в случае если она выдается иным сервером. Четко все увидеть помогут функции Developer Tools с функциями отключения или очистки кэша.
- Если «тормоза» есть при редактировании страничек своего веб-сайта, можно исключать по очереди блоки и элементы внешней статистики и рекламы со странички и, обновляя, определять, в чем же проблема.