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