juise
0
Ну если вы все таки подготовите честные бенчмарки и приоткроете завесу тайны, что же все таки там у вас под капотом это будет намного лучше, нежели голословное декларирование производительности вашего кода!
juise
0
Если так, то это более близко к реальности.

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

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

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

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

Подскажите пожалуйста, где я ошибся?
juise
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
, так что, мне кажется вы где-то немного ошибаетесь.
juise
0
Возможно несколько наивный вопрос, я в этом абсолютный дилетант. Правильно ли я понимаю, что через каждые 25 секунд коннект рвется и заново инициируется скриптом?
juise
+1
Уважаемые, теме более полугода, все уже давно изменилось. Используйте появившиеся в uwsgi фичи, они прекрасно дружат с flask'ом, django и самим python'ом.
juise
0
Уважаемый, а подскажите пожалуйста, чем вы профилировали нагрузку на систему (память, диски, проц, сеть)? Абсолютно не имею представления как это делается в windows.
juise
0
Это как раз и есть тот колхоз, который мне бы не хотелось разводить в стартовых скриптах ) В данный момент, версия uWSGI 0.9.7.2 не позволяет использовать предложенный мной вариант, ведет себя аномально. Сейчас посматриваю в сторону Emperor.
juise
0
Что именно Вам непонятно в «обрезанном конфиге нджинкса»?
juise
0
Мне не хотелось колхозить стартовые скрипты для запуска на каждый django-проект, а запускать все традиционным для FreeBSD способом через rc.conf. Опять таки, уменьшить количество webapp.xml файлов, но это 10е, а то и 100е дело.

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

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

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