• 0
    Ну если вы все таки подготовите честные бенчмарки и приоткроете завесу тайны, что же все таки там у вас под капотом это будет намного лучше, нежели голословное декларирование производительности вашего кода!
    Targetix — разработка full-stack RTB технологий
  • 0
    Если так, то это более близко к реальности.

    Однако с точки зрения моего опыта, DSP редко может обработать запрос за 2-3 мс. Расскажите, какие действия выполняет DSP при запросе, что он обрабатывается за 2-3 мс? Я не пытаюсь Вас закидать шапками, мне просто интересен Ваш опыт. Было бы очень любопытно посмотреть на Ваши бенчмарки!
    Targetix — разработка full-stack RTB технологий
  • 0
    Я возможно что-то не совсем понимаю, но:

    — имеем 7k запросов в 1 секунду (1000 миллисекунд) на один сервер с 6 ядами, за время отклика возьмем 10 миллисекунд, тогда:

    7000 запросов * 10 миллисекунд / 1000 миллисекунд = 70 запросов должен обработать сервер за 1 миллисекунду

    70 запросов / 6 ядер = 11 запросов каждое ядро должно обработать за 1 миллисекунду

    Подскажите пожалуйста, где я ошибся?
    Targetix — разработка full-stack RTB технологий
  • 0
    Спасибо за статью, но вот вы пишите:
    — Повышенная произвдительность (до 2000 заявок в секунду в одном потоке, более 10 млн заявок в торговый день).

    а чуть выше этого:
    Теперь скорость обработки заявки в системе составляет от 500 микросекунд до 2 — это очень хороший результат. Общее время прохождения заявки от момента попадания в «Матрицу» до вывода ее в биржевые системы составляет от 2 до 5 миллисекунд

    «от 500 микросекунд до 2» — это какой-то крайне дичайший результат, ибо на моем домашнем ноуте (достаточно старом) Intel Core 2 Duo 2.4 ГГц, сложение двух чисел в среднем занимает 8 микросекунд:

    1> timer:tc(fun() -> 1 + 1 end).
    {12,2}

    7> timer:tc(fun() -> 1 + 1 end).
    {5,2}

    Теперь, если представить ваши вычисления на матрицах, ранг которых очевидно не два и не пять, то все элементы вряд ли поместятся в регистры процессора, а чтение из памяти в данном случае будет крайне дорогое, чтоб уместиться в
    от 500 микросекунд до 2
    , так что, мне кажется вы где-то немного ошибаетесь.
    Технологии фондового рынка: Брокерская торговая система
  • 0
    Возможно несколько наивный вопрос, я в этом абсолютный дилетант. Правильно ли я понимаю, что через каждые 25 секунд коннект рвется и заново инициируется скриптом?
    Long Polling от А до Я своими руками
  • +1
    Уважаемые, теме более полугода, все уже давно изменилось. Используйте появившиеся в uwsgi фичи, они прекрасно дружат с flask'ом, django и самим python'ом.
    Nginx + uWSGI + Django, один из вариантов запуска
  • 0
    Уважаемый, а подскажите пожалуйста, чем вы профилировали нагрузку на систему (память, диски, проц, сеть)? Абсолютно не имею представления как это делается в windows.
    Мощный сервер БД за чуть более 2000$
  • 0
    Это как раз и есть тот колхоз, который мне бы не хотелось разводить в стартовых скриптах ) В данный момент, версия uWSGI 0.9.7.2 не позволяет использовать предложенный мной вариант, ведет себя аномально. Сейчас посматриваю в сторону Emperor.
    Nginx + uWSGI + Django, один из вариантов запуска
  • 0
    Что именно Вам непонятно в «обрезанном конфиге нджинкса»?
    Nginx + uWSGI + Django, один из вариантов запуска
  • 0
    Мне не хотелось колхозить стартовые скрипты для запуска на каждый django-проект, а запускать все традиционным для FreeBSD способом через rc.conf. Опять таки, уменьшить количество webapp.xml файлов, но это 10е, а то и 100е дело.

    Если бы FreeBSD имела возможность запуска «управляется проект стандартным скриптом(projectname start|stop|reload)», то я бы выбрал его из соображений атомарности и автономности воркеров/проектов. Но FreeBSD не имеет такой возможности, поэтому я пренебрег этим.
    Nginx + uWSGI + Django, один из вариантов запуска
  • 0
    Спасибо idle, FeNUMe, исправил Django-приложение, на Django-проект.

    «Еще у вашего способа минус — если нужно перезапустить 1 проект, вы вместе с ним перезапустите остальные.» — Да, тут я с вами абсолютно согласен, но для решаемых мной задач это абсолютно не критично. Что касается способа запуска, который используется у вас, он как раз и является каноническим )
    Nginx + uWSGI + Django, один из вариантов запуска
  • 0
    Вы возможно правы, с Django работаю исключительно как системный администратор, мне дают каталог с Django-приложением и говорят — «надо»! «Разные django-проекты на одном сайте?.. Смысл?» — а почему бы и нет? Отдельные задачи, отдельные Django-проекты.
    Nginx + uWSGI + Django, один из вариантов запуска
  • 0
    Имеются в виду именно разные проекты — «конгломерат Django-приложений». Жаль что не написали, сэкономили бы мне время ) А содержимое location'ов nginx у вас такое же, или вы делаете как-то по другому?
    Nginx + uWSGI + Django, один из вариантов запуска
  • 0
    А у меня вот так правила написаны:

    # Internet settings
    oif=«em0»
    onet=«84.237.22.0»
    mask=«255.255.255.128»
    oip=«84.237.22.3»

    # Intranet settings
    iif=«re0»
    inet=«192.168.0.0»
    imask=«255.255.255.0»
    iip=«192.168.0.1»

    # Rules for NAT
    ${ipfw} nat 1 config log if ${oif} same_ports
    ${ipfw} add 50 nat 1 all from ${inet}:${imask} to any out recv ${iif} xmit ${oif}
    ${ipfw} add 50 nat 1 all from any to ${oip} in recv ${oif}

    При использовании модификаторов recv и xmit нет надобности использовать: «table\(10\) via em0, где table 10 – не идет через нат», к тому же как мне кажется это намного удобнее нежели использование модификатора via.

    Естественно это справедливо только в ряде случаев.
    Обзор и сравнение способов настройки NAT на FreeBSD
  • 0
    Простите, а под Feedback Loops подразумеваются callout'ы?
    DKIM — это просто
  • +1
    reject_non_fqdn_helo_hostname — я бы это убрал, как показывает практика, многие администраторы почтовых серверов игнорируют соглашение об FQDN, к тому же в RFC описана передача hello в формате FQDN как should, а не must! Самый яркий пример в моей практике — Альфа-Банк. Во время сесси проверка делалась по 3м разным доменам — в hello один, в DNS другой, а в адресе отправителя третий — и ни один не был в формате FQDN.
    Неприступный почтовый сервер, или жизнь без спама