Я попросил скинуть ссылку на подобный сервис, который делает то же что и мы за меньшие деньги. Сервисов много, у каждого свои плюсы/минусы. И мы — не лучшие, мы другие. Поэтому хотим, чтобы о нас люди тоже услышали )
Вы перед тем, как предлагать альтернативный сервис вообще смотрите его возможности/цены?
Давайте смотреть. Опять же — UI. Смотрим www.host-tracker.com/Payment/Packages
Что вы хотите сравнивать? Чем host-tracker лучше?
Ok, смотрим ping-admin.
1) Интерфейс — no comments. Да, этот сервис умеет делать проверки, которых нет у нас. Мы на данный момент не видим смысла проверять всё и вся.
2) Обычному человеку не нужно знать, каким методом будет идти проверка (HEAD, GET, POST...)
3) Партнерка у нас выгоднее
4) У нас есть whois информация, уведомления об окончании срока действия домена и хостинга, а также заметки, финансы, короче набор для удобного менеджмента домена.
5) Цены — ну не смешите, habrastorage.org/storage2/9da/be2/57a/9dabe257a34b05eb2ae71364d09ba72b.png
Это первое, что бросается в глаза…
Просто зарегистрируйтесь у нас и 2 недели потестите, поймете разницу.
Вопрос к минусующим: у вас это хобби или как? Мы пытаемся рассказать о молодом отечественном проекте, статья прошла фильтр модераторов с четвертого раза, а вы опускаете вместо того, чтобы поддержать. Еще раз повторю — мы не так давно открылись широкой публике, у нас нет какого-то пройденного критического срока для стартапа. В статье попытались вкратце описать трудности, с которыми столкнулись. Рассказывать об архитектуре, показывать графики и раздавать советы по HA будем, когда придет время…
Столкнулись много с чем и наверное обо всем этом пишут в книгах и интернете:
Delayed Job плохо подходит как серьезный Scheduler для long-running задач.
Разбивать и «держать» всю базу в оперативке.
Обязательно использовать мультиплексор соединений.
Не пытаться серьезно использовать ruby (mri) в многопоточных процессах, лучше evented ruby, либо jruby.
Преждевременная оптимизация — не всегда зло.
Из нетривиальных вещей можно назвать парсинг whois. Выдача whois нестандартизирована, поэтому парсить ответы от регистраторов весьма и весьма тяжело. Всё может поменяться в любой момент. Если регистратор не выдаёт по 43 порту каких либо данных, то это не значит что он их не выдаёт вообще. Можно отправить запрос whois серверу и возможно ваш ip включат в исключения. Для некоторых зон нужно делать задержки между запросами.
Проект очень молодой, все может поменяться, мы серьезно открылись всего 2 недели назад. В бете были пол-года. Поэтому не стоит принимать все близко к сердцу ;)
Первое, с чем мы столкнулись — это лаги бд. База тупила из-за большого количества коннектов. У PostgreSQL каждый коннект обслуживается отдельным процессом. Переключения между процессами дорогого стоит для системы. Решение было найдено быстро — PgBouncer. Это дало нам время выявить другие «узкие» места в бд: убраны ненужные и добавлены нужные индексы, настроено кеширование часто запрашиваемых данных. На данном этапе рассматривается вопрос мульти-мастер репликации и сложности, с ней связанные.
Проверка доступности организована при помощи нескольких воркеров в каждой точке пинга. Каждый воркер работает в несколько потоков. Честно говоря, пока что ресурсов нужно много (ruby не самый подходящий выбор для этих дел). Тема «threaded vs evented» поднимается довольно часто. Где-то лучше потоки, где-то ивенты.
Фоновые джобы (whois, security, etc) работают по принципу разделения тасков между несколькими процессами на разных машинах. Мы используем различные системы: delayed_job, resque и свои наработки.
Из NoSQL активно юзается Memcache, Redis и MongoDB. У каждого свои плюсы и недостатки, каждый новый день иногда преподносит неожиданные сюрпризы.
Давайте смотреть. Опять же — UI. Смотрим www.host-tracker.com/Payment/Packages
Что вы хотите сравнивать? Чем host-tracker лучше?
1) Интерфейс — no comments. Да, этот сервис умеет делать проверки, которых нет у нас. Мы на данный момент не видим смысла проверять всё и вся.
2) Обычному человеку не нужно знать, каким методом будет идти проверка (HEAD, GET, POST...)
3) Партнерка у нас выгоднее
4) У нас есть whois информация, уведомления об окончании срока действия домена и хостинга, а также заметки, финансы, короче набор для удобного менеджмента домена.
5) Цены — ну не смешите, habrastorage.org/storage2/9da/be2/57a/9dabe257a34b05eb2ae71364d09ba72b.png
Это первое, что бросается в глаза…
Просто зарегистрируйтесь у нас и 2 недели потестите, поймете разницу.
Delayed Job плохо подходит как серьезный Scheduler для long-running задач.
Разбивать и «держать» всю базу в оперативке.
Обязательно использовать мультиплексор соединений.
Не пытаться серьезно использовать ruby (mri) в многопоточных процессах, лучше evented ruby, либо jruby.
Преждевременная оптимизация — не всегда зло.
Из нетривиальных вещей можно назвать парсинг whois. Выдача whois нестандартизирована, поэтому парсить ответы от регистраторов весьма и весьма тяжело. Всё может поменяться в любой момент. Если регистратор не выдаёт по 43 порту каких либо данных, то это не значит что он их не выдаёт вообще. Можно отправить запрос whois серверу и возможно ваш ip включат в исключения. Для некоторых зон нужно делать задержки между запросами.
Проект очень молодой, все может поменяться, мы серьезно открылись всего 2 недели назад. В бете были пол-года. Поэтому не стоит принимать все близко к сердцу ;)
Проверка доступности организована при помощи нескольких воркеров в каждой точке пинга. Каждый воркер работает в несколько потоков. Честно говоря, пока что ресурсов нужно много (ruby не самый подходящий выбор для этих дел). Тема «threaded vs evented» поднимается довольно часто. Где-то лучше потоки, где-то ивенты.
Фоновые джобы (whois, security, etc) работают по принципу разделения тасков между несколькими процессами на разных машинах. Мы используем различные системы: delayed_job, resque и свои наработки.
Из NoSQL активно юзается Memcache, Redis и MongoDB. У каждого свои плюсы и недостатки, каждый новый день иногда преподносит неожиданные сюрпризы.
А может 24-байтное?