Настройки поиска (Страница 2 из 2)

Как то не рационально всё получается.

Смотрите, скорость доступа к провайдеру (канальная часть) плюс задержка на DNS, соединение и скорость ответа и так обсчитываются (уже потом, все данные "дружно" аппроксимируются, а на их сопоставлении и строится рейтинг), и вот вводить сюда некий файл лежащий у провайдера (пусть даже и заведомо искомого размера) это лишь добавить себе геморроя на ровном месте. Зачем? Данные по доступности (именно по доступности, заметьте) уже получены.

Другой вопрос что:

Но тут заметьте, что размер, объём т.е. количество передаваемых (в килобайтах) данных на хост абонента, зависит исключительно от дизайна самого сайта (головной страницы) хостёра, а в купе с этим:
- С одной стороны сайт хостера может "весить" 0,1 мб и быть на отвратительном канале, к которому конектится юзер, скажем, по аналоговому модему;
- С другой стороны "главная" может весить 1,2 мб и находится в аккурат на М9 к которому конектится юзер на Е1 потоке (и скрипты/сервер-платформа у хостера не тормозят).

Бр-р-р... Куда вы нас загоняете? 8-)

Вот интересный вопрос:

Толк здесь в том, что бы избавиться от логичных вопросов типа: "у меня этот хостинг "летает" - заданный юзером, который в том же городе что и его хостинг (на том же канале, через один хоп и пр.). Поэтому, важно получить аппроксимированные данные по каждому из хостингов, что бы потом интегрировать их в единую таблицу рейтинга хостингов, где все хостёры оцениваются по единому критерию.
Вот собственно поэтому, есть толк мониторить хост из многих точек (что то сродни средней скорости автомобиля на трассе: порою вы едите 140 км/час, а вот средняя скорость по маршруту из точки "А" в точку "Б" составит 68 км/час). не совсем точно конечно, но если таких автомобилей 12 и есть данные по всем ним, то можно понять среднее  время требуемое для достижения города без оглядки на мнение "шумахера": я доехал за три часа. Хотя все мы и понимаем, что в среднем потребуется 4,5 часа.

Это есть здесь но вот вы абсолютно верно заметили что в самом рейтинге ссылки на форму подачи заявки нет. Ok. Добавим. Спасибо

Да, делаем. Появится в ближайшее время.

P.S. А это:
http://ping-admin.ru/free_test/result/1 … t342j.html
это, это ваш домен?

Э-э-э...
В смысле, иметь возможность приписать к ошибке комментарий от себя, что-то вроде:
"Не пускать Барсика в серверную, жрёт кабели"  или что то другое? Верно? 8-)
---

Тогда, наверное было бы логичным:

а) все эти комментарии складывать в единый стек, где будет два столбца:
дата и собственно комментарий;
б) при нажатии на комментарий, иметь возможность просмотреть ошибку более подробно.

?

"Оно" пишет то, что "оно" видит   { - Шутка конечно 8-) - }

Логика здесь следующая.

Если вы добавили в "Рейтинг хостингов" URL,  то будет мониторится конечный IP (url через dns к IP).
Если вы добавили IP в "Рейтинг хостингов" то всё равно будет мониторится конечный URL "через dns к указанному IP".

!
Вот кстати, именно "и поэтому тоже", иногда в "Рейтинге хостингов" можно наблюдать "странную вещь" (странную только на первый взгляд) а именно: В таблице ранжирования, в самом её низу, может находится некий провайдер со статусом ошибки, при подробном рассмотрении которой можно увидеть подробное описание: "Ещё продолжается" хотя сам сайт провайдера уже может быть доступен при "клике" по ссылке на провайдера из таблицы рейтинга.
Дело в том, что пока DNS "не устаканится" и сайт (провайдера) не станет доступен всем (из всех точек мониторинга и пр.)  система не считает его работоспособным, и это условие, одинаково применимо ко всем участникам рейтинга.

Т.е. речь идет о расширении внутренней статистики партнерской программы, которую можно видеть в "личном кабинете".
Вы знаете, мы тут сейчас сильно озадачены вводом нового под-сервиса, ориентированного именно на SEO-шников (и именно сервиса в рамках Ping-Admin.Ru).  Вот после его официального запуска (где то к концу месяца) мы вернемся к "личному кабинету" и попробуем реализовать высказанные вами пожелания.

P.S. Кстати спасибо за ваши комментарии т.к. они весьма и весьма полезны. И в общем то всегда, читаем их с удовольствием

Леонид, здравствуйте!

Интересное предложение. Подумаем как реализовать его наиболее удобно для пользователя. Скорее всего появится опциональная функция: "Активировать перепроверку с интервалом "Х" после первой ошибки".
В этой опции в качестве параметра "Х" можно будет задать внештатную проверку через желаемые интервалы, а затем, уже после получения некоторой "раз подряд" ошибки (в данном примере, после пятой подряд проверки с интервалом в одну минуту) и будет оправлено уведомление.

На фигуре ниже можно посмотреть как это будет работать.-*
*-На изображении, над временной линией изображена текущая схема проверки доступности, а под линией, схема с функцией дополнительной перепроверки.

1.0 Текущая схема проверки работоспособности (по вашим настройкам).

- 0-10-20-30 минут, это заданные пользователем перепроверки с интервалом 10 минут;
- "Check1" - Первое определение недоступности;
- "Check2" - Второе определение недоступности и отправка оповещения.;

2.0 Схема с новой подсистемой проверки работоспособности.

- На 10-й минуте недоступность определена первый раз;
...и если активирована дополнительная перепроверка после первой ошибки, то:
- Выполняются дополнительные перепроверки работоспособности (доступности) проверяемого сайта: check1.1; check1.2 и.т.д. вплоть до check1.5 после выполнения которой и получения отрицательного результата, будет выслано оповещение о неработоспособности.

На приведенной конфигурации это и показано под временной линией: Пять ежеминутных перепроверок подряд, и отправка сообщения о неработоспособности после пятой.  Разумеется,  что интервалы дополнительных перепроверок и их количество можно будет выставить в настройках интерфейса.

Приведенная схема приведена конечно "в первом приближении" и в практическом исполнении это будет выполнено несколько иначе т.к. придётся решить несколько логических и технических задач которые "тянет за собой" ввод этой опции. В любом случае, идея очень неплоха, будем делать.

And79, вы знаете, мы тут сами удивлялись в отношении своих-же ресурсов (когда Пинг-Админ заработал). Тот-же Refer.Ru  выдавал 500-ую ошибку в момент обновления (перегенерации) базы данных, это примерно 10 - 20 минут в сутки. Когда обнаружили, что пинг-админ может решать чисто практические задачи (т.е. реально мониторить работу собственного сервиса) решили сделать его общедоступным проектом (до этого, он мониторил наши собственные ресурсы). Причем, самого названия Пинг-Админ еще не существовало, а продукт назывался: "СОМ" т.е. Система Оперативного Мониторинга. Это уже потом, кому-то в команде "стукнуло в голову" предложить перевести систему в "общее пользование". Так и появился Ping-Admin

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

Спасибо Sandamond за отзыв.

Если что то вы посчитаете нужным добавить к сервису, пишите. Будем дорабатывать "на лету"