Почему лежит Liveinternet? (не лежит, проблемы с доступом)

Развитие событий: Открытка компании: провайдеры забанили liveinternet-у https трафик? (2 июля 2015)

Комментарий Roem.ru: не лежит, проблемы с каналом:

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

-------
Сидя в офисе, подумал, что у моего провайдера проблемы с маршрутизацией и даже проверять не стал (там пров чаще намного лажает, чем сервисы лежат). Но придя домой, обратил внимание, что на всех сайтах подвисает на обращении к counter.yadro.ru (именно он раздает картинки счетчиков и пишет логи, которые потом преобразуются во всем известные отчеты). Ну и попробовал зайти на liveinternet.ru — безуспешно: «Время ожидания соединения истекло».

ping liveinternet.ru
PING liveinternet.ru (88.212.196.87): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 88.212.196.87: icmp_seq=1 ttl=56 time=9.842 ms
Request timeout for icmp_seq 2
64 bytes from 88.212.196.87: icmp_seq=3 ttl=56 time=4.722 ms
Request timeout for icmp_seq 4
64 bytes from 88.212.196.87: icmp_seq=5 ttl=56 time=4.997 ms
64 bytes from 88.212.196.87: icmp_seq=6 ttl=56 time=4.784 ms
64 bytes from 88.212.196.87: icmp_seq=7 ttl=56 time=9.262 ms
64 bytes from 88.212.196.87: icmp_seq=8 ttl=56 time=10.695 ms
^C
--- liveinternet.ru ping statistics ---
10 packets transmitted, 6 packets received, 40.0% packet loss
round-trip min/avg/max/stddev = 4.722/7.384/10.695/2.584 ms

Добавить 20 комментариев

  • Ответить

    Провайдер сообщил, что производятся работы. Сообщаем Вам, что с 22:00 26.01.2012 до 7:00 27.01.2012 будут проводится внеплановые работы на оптоволоконной сети на территории Курчатовского института. Причина проведения работ: переварка оптических кабелей. На время с 22:00 до 07:00 ожидается снижение скорости доступа по ряду направлений: зарубежные сети, ТТК, Билайн, МТС, Ростелеком по причине использования резервных каналов связи. Также, на период проведения работ не исключены и полные перерывы связи. По факту сейчас потери в учете и недоступность около 70% http://img-fotki.yandex.ru/get/4600/14251823.0/0_8b2b1_64b500cb_orig

  • Ответить

    Провайдер сообщил, что производятся работы. Это ли не сигнал к тому, чтобы поставить аварийные сервера в альтернативном ДЦ для отработки статистики? Ведь главное писать логи (а картинки в таких ситуациях можно без цифр отдавать — сделать красивые заглушки). То что они размотаются с опозданием — не проблема. Да и сайтов огромное количество подставляете, у них «подвисание» происходит.

  • Ответить

    > Да и сайтов огромное количество подставляете, у них «подвисание» происходит. Для сайтов проблемы счетчика LiveInternet выражаются только в том, что в браузере продолжает крутиться значок загрузки страницы. Никакого влияния на внешний вид сайта тормоза счетчика не оказывают. Если только владелец сайта не решил сам себя подставить, повесив какую-то содержательную деятельность на javascript-функцию OnLoad.

  • Ответить

    Для сайтов проблемы счетчика LiveInternet выражаются только в том, что в браузере продолжает крутиться значок загрузки страницы Я на новые сайты не смотрю, пока этот значок не закончит крутится (какое-то психологическое давление что ли). Не знаю, много ли таких как я… Если только владелец сайта не решил сам себя подставить, повесив какую-то содержательную деятельность на javascript-функцию OnLoad Это была шутка с Вашей стороны? Т.е. использование window.onload — это самоподстава?

  • Ответить

    > Т.е. использование window.onload — это самоподстава? Да. Вы вставили с десяток внешних элементов в страницу и сделали так, чтобы ваш сайт вообще не работал, если хотя бы у одного из них проблемы. Вы не то что контролировать их не можете, вы даже не всегда можете знать, что они не работают. Вы сами сознательно повысили неустойчивость вашей системы в разы. Это игра в русскую рулетку с 5 патронами из 6.

  • Ответить

    Ну т.е. мысль понятна. Не стОит доверять этому счетчику. Кстати, я также не могу контролировать провайдеров, хостинг и прочие вещи, но как-то они не заявляют, что не стОит пользоваться их услугами. Вот когда яндекс ложится и не загружается сайт, потому что синхронный код рекламного блока установлен надо также говорить — нефиг ставить то, что контролировать не можете (про асинхронный код не надо в ответ упоминать — он сравнительно недавно появился). Вообще стоило бы и свои ошибки признавать.

  • Ответить

    > Кстати, я также не могу контролировать провайдеров Вы совсем не понимаете разницы между зависимостью от одного фактора и зависимостью от 10 факторов? Если вероятность сбоя у хостинга 1%, то в нормальном случае вероятность неработы вашего сайта 1%, ваш сайт не работает только тогда, когда не работает только ваш хостинг. Если же вы повесили 10 разных внешних картинок и сделали, что ваш сайт отображался по onload, то ваш сайт не будет работать, если не работает ваш или любой из 10 разных хостингов/сайтов, вероятность неработы вашего сайта 11%. Совсем не чувствуете разницы между 1 и 11? Разницу, которую вы получили на абсолютно ровном месте, всего лишь использовав onload, оправданное применение которому еще нужно очень хорошо поискать.

  • Ответить

    Вы совсем не понимаете разницы между зависимостью от одного фактора и зависимостью от 10 факторов Во-первых, кто говорил про 10 факторов? Висят на сайтах, как правило 1−2 внешних счетчика. А зачастую вообще только li (нужны примеры?). Во-вторых, априори вебмастера предполагают, что такие монстры, как Яндекс, Мейл и лайвинтернет надежнее, чем стандартные хостеры (не зря многие пользуются тем же yandex.st). Вы как раз развенчиваете миф о «монстровости» лайвинтернета. Типа «ребята, не рискуйте, мы можем и лечь». Ну и на том спасибо.

  • Ответить

    Вы я смотрю умничать сильны Максим, многим Вашим пользователям статистики, вообще по барабану кто, где, и какие кабеля меняет и смешная формулировка «недоступность около 70%". А что мы вставляем в свои страницы (кроме неизменного по правилам LiveInternet кода счетчика) это уж наше дело. И крутящийся значок конкретно раздражает, даже не админов, мы понимаемс… а обычных пользователей сайтов.

  • Ответить

    Во-вторых, априори вебмастера предполагают, что такие монстры, как Яндекс, Мейл и лайвинтернет надежнее, чем стандартные хостеры (не зря многие пользуются тем же yandex.st). Вы как раз развенчиваете миф о «монстровости» лайвинтернета. Типа «ребята, не рискуйте, мы можем и лечь». Ну и на том спасибо. Вам вообще-то дело говорят: если сайт не открывается, пока не подгрузятся все внешние элементы, это говорит о несовершенстве верстки. Падают все, так что не нужно слепо надеяться на чью-то надежность.

  • Ответить

    Вам вообще-то дело говорят: если сайт не открывается, пока не подгрузятся все внешние элементы Да что вы всё додумываете? 10 внешних картинок, сайт не открывается… На onload может быть много приятных вещей повешено. И неисполнение их из-за неработоспособности статистики говорит о том, что нужно выбирать более устойчивую к встряскам статистику (к сожалению, без статистики вообше — никуда). Особенно неприятно, когда разработчики системы говорят, что мы сами виноваты, что ЛИ поставили. Ну и еще там ДЦ в курчатовском виновато. Может, еще кто… ЗЫ и не надо про $(document).ready вспоминать. У него тоже есть свои недостатки)

  • Ответить

    spsh, Одна из парадигм правильного проектирования сервиса подразумевает, что он старается жить максимально полной жизнью в условиях неработоспособности чего угодно. Отвалились внешние счетчики — черт с ними, давайте без них. Умерло хранилище картинок — черт с ним, давайте покажем страничку. Другая парадигма — напротив — контролируем, что все компоненты живы, если кто-то умер — не отдаем ничего, показываем, что «что-то мол пошло не так, заходите попозже». Есть и другие парадигмы. То, что нередко доводится встречать среди разработчиков более или менее серьезных сервисов — это гибрид двух вышеупомянутых парадигм: разделение компонент на критические и некритические. От некритических ничего не зависит, они существуют изолированно, и могут умирать незаметно для окружающих; смерть чего-то критического — это приостановка сервиса. Если говорить о сервисах статистики, нетупящих в природе не существует. Уйти от зависимости от них и заменить onload на listening event’а загрузки ровно того, что нужно (с обходом тех капканов, которые готовит $(document).ready) — это до 50 строчек js-кода. Можно, конечно, последовательно бегать по граблям и после каждого даунтайма того или иного сервиса менять его на следующий — но вы так довольно быстро переберете все варианты и останетесь просто без статистики.

  • Ответить
    Альтер Эго

    Асинхронно надо js вставлять, Максим. Асинхронно, а не так, как в 97 году вставляли картинкой. (function () { var ga = document.createElement (‘script’); ga.type = ‘text/javascript’; ga.async = true; ga.src = (‘https:’ == document.location.protocol? ‘https://ssl’: ‘http://www’) + ‘.google-analytics.com/ga.js’; var s = document.getElementsByTagName (‘script’)[0];s.parentNode.insertBefore (ga, s); })();

  • Ответить

    Ура! Максим, а код счетчика все же пересмотрите пожалуйста. Ведь правильный мыслительный процесс с вашей стороны гораздо эффективнее мыслительного процесса миллионов хомячков по-отдельности. :)

  • Ответить

    вот уж не думал что такой крупняк как li может весь одном дц хоститься. а потом ещё пальцем тыкать какие вебмастера тупые, что onload используют. соринка vs бревно, однако.