Pull to refresh
8
0
Send message

dlang-requests — типа python-requests, только для D

Reading time 4 min
Views 4.3K
Доброго времени суток!

Хочу познакомить вас с библиотекой dlang-requests. Для чего она? Для D она хочет быть тем-же, чем python-requests является для python, то есть — удобным http-(и ftp) клиентом. Автор клялся, что при написании библиотеки его целями были:

  1. удобный, простой интерфейс
  2. производительность сопоставимая с libcurl
  3. сочетаемость со стандартной библиотекой D

Первая часть статьи будет состоять из примеров использования dlang-requests для наиболее часто встречающихся задач.
С чего начать?
Total votes 7: ↑6 and ↓1 +5
Comments 25

Мониторинг связности в сети сервисов

Reading time 7 min
Views 6.8K

Предисловие

Наш основной проект — оптимизация показов рекламы в социальных сетях и мобильных приложениях. Каждый показ баннера — результат взаимодействия достаточно большого числа сервисов, расположенных на разных серверах, иногда в разных датацентрах. Естественно что существует задача мониторинга связи между серверами и сервисами. О том, в каком виде стоит эта задача, какие решения подходят, какие не подходят — речь дальше.

Читать дальше →
Total votes 4: ↑4 and ↓0 +4
Comments 3

Cassandra глазами Operations

Reading time 9 min
Views 12K
Основной проект компании, в которой я работаю, посвящен оптимизации показов рекламы в приложениях на фейсбуке и на мобильных устройствах. На сегодняшний день проект обслуживает до 400 миллионов уникальных посетителей в месяц, работает на тысяче с лишним виртуальных серверов. Количество серверов и обьемы данных, которые должны обрабатываться двадцать четыре часа в сутки, ставит перед разработчиками ряд интересных проблем, связанных с масштабируемостью и устойчивостью системы.

Оптимизация показов — большой процесс, одной из частей которого является сохранение и анализ цепочки событий, связанных с жизненным циклом баннера — показ, клик, конверсия, … всё это начинается с сохранения записей о событиях. Каждое из событий происходит на одном из множества серверов, причем, по понятной причине мы стараемся обслужить всю цепочку в одном месте — в этом случае не нужно заботиться о том как собрать в целое разбросанные части. Но в реальной жизни случается что угодно — сервера падают, сеть не работает, софт апгрейдится или перегружен — в общем, по многим причинам обслуживание последовательных событий иногда происходит на разных серверах и даже в разных датацентрах и к этому нужно быть готовым.

Задача которую нужно было решать — каким образом хранить, искать, модифицировать информацию о последовательности событий при следующих условиях:


  • события могут происходить на разных серверах и в разных датацентрах (восточный и западный берег США, Европа)
  • интервал между событиями — от долей секунды до нескольких дней
  • к моменту получения завершающего события (например конверсия) информация обо всей цепочке должна быть на руках
  • время жизни информации — примерно десять дней, после чего она должна быть удалена, желательно автоматически, через TTL
  • темп чтения/записи событий — сотни или тысячи в секунду
  • Время ответа: желательное — до 10мс, допустимое — в пределах 50мс, максимальное — до 100мс
  • информация должна быть доступна «всегда» — независимо от аварий железа, сети, апгрейдов
  • система должна легко масштабироваться: добавление новых серверов, датацентров должно происходить прозрачно для остальных сервисов (допустима деградация времени ответа в заданных пределах).

Последние два пункта очень важны для бизнеса и просто жизненно важны для опс инженеров если они хотят спокойно выполнять свои обязанности днём, и спокойно спать ночью.
Читать дальше →
Total votes 18: ↑18 and ↓0 +18
Comments 12

Information

Rating
Does not participate
Registered
Activity