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

Да. Действительно забавно: http://ping-admin.ru/free_test/result/1327608820307sryjfxx834xo8z10k1d.html Ну, очередная жопа. Ничего страшного, поднимутся!

Провайдер сообщил, что производятся работы. Сообщаем Вам, что с 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); })();

Связь восстановили.

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

Да я уже кинулся плагиатить асинхронный код логотипа у Метрики, а там imgsrc 97 года.

в последнее время Ли очень часто сбоит, что-то происходит в королевстве кривых зеркал

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

Ну вы же в курсе, что весь Li.ru размещен на ноутбуке, который стоит на столе у Клименко? Чудеса оптимизации