Хотя, с другой стороны саппорт хорош:
1. Так примонтировали рейд, что он отвалился. Позже я узнал, что у них это не первый случай.
2. Сказали что винт «вышел из строя на физическом уровне восстановление данных невозможно».
3. Двое суток «занимались восстановлением».
4. Писали восстанавливаемые данные на «убитый» винт.
На самом деле, моей целью не была отрицательная пропаганда Инфобокса. Все-таки год dedicated-сервер там простоял без каких-либо проблем (кроме фатала в мае). Colocation я поставил к ним же. Т.к.:
1. проблемы уровня датацентра случаются очень редко (вроде проф.работ или отключения электричества),
2. колоку там стоять лучше, нет проблем с доступом к серверу
3. пока ничего лучше я в Питере не нашел, исходя из собственного опыта и рекомендаций знакомых.
Давайте так: вы примите во внимание что информация о цвете ссылок только из этого блока. А как именно он строится известно только хабра-менеджерам и хабра-программистам.
Система, на которую я дал ссылку, занимается только тем, что отдает готовые картинки. Система, при помощи которой я рисовал графы, позволяет менять очень много параметров, стрелки же потому и разноцветные, что я так указал.
Я не знаю, буду ли обновлять эти картинки чтобы выверять цветовые комбинации и т.п. Разве что хабра-программисты сделают мне гейт с view из sql с теми данными которые я собираю пару часов :-)
Я предполагаю что все дело в кеше Хабра. Я запускаю скрипт в 5 потоков, которые собирают пользователей, начиная с 1, 300, 600, 900 и 1200 страниц рейтинга. Как только происходит какое-то событие, например кому-то карму подняли, то весь рейтинг перестраивается и пользователь, который должен был вот-вот попасть под скан, переходит на страницу, которая у меня отмечена как просканированная.
Чтобы собрать идеально всех, необходимо чтобы вся система «замерла» на момент сканирования, но это ведь невозможно.
Проблема в том, что на хабре нет ни единого места, где есть список пользователей, который бы не изменялся от запроса к запросу.
Я собирал пользователей отсюда, надеясь на то что это наиболее постоянное место. Но тем не менее, с каждым новым проходом по всем страницам, я получал новых пользователей. При контрольной сборке таких проходов было три.
Вероятно вам не повезло, и вы оказались в числе тех, кто не попался ни разу, уж извините.
100 пользователей в минуту загружают по 5 новостей, к каждой из которых 200 комментариев. Итого имеем 100 000 необходимых для загрузки аватар. Если прикинуть, что аватары стоят у 50% пользователей (на редком сайте), то мы ежеминутно имеем 50 000 паразитных некешируемых запросов к серваку.
1. Так примонтировали рейд, что он отвалился. Позже я узнал, что у них это не первый случай.
2. Сказали что винт «вышел из строя на физическом уровне восстановление данных невозможно».
3. Двое суток «занимались восстановлением».
4. Писали восстанавливаемые данные на «убитый» винт.
1. проблемы уровня датацентра случаются очень редко (вроде проф.работ или отключения электричества),
2. колоку там стоять лучше, нет проблем с доступом к серверу
3. пока ничего лучше я в Питере не нашел, исходя из собственного опыта и рекомендаций знакомых.
Я не знаю, буду ли обновлять эти картинки чтобы выверять цветовые комбинации и т.п. Разве что хабра-программисты сделают мне гейт с view из sql с теми данными которые я собираю пару часов :-)
Чтобы собрать идеально всех, необходимо чтобы вся система «замерла» на момент сканирования, но это ведь невозможно.
Я собирал пользователей отсюда, надеясь на то что это наиболее постоянное место. Но тем не менее, с каждым новым проходом по всем страницам, я получал новых пользователей. При контрольной сборке таких проходов было три.
Вероятно вам не повезло, и вы оказались в числе тех, кто не попался ни разу, уж извините.
Ну и кому оно такое надо?
Нет, там нет такой возможности.