RedHat анонсировало CentOS 8 как последнюю стабильную версию, которую они поддерживают и предлагают всем сфокусируется на CentOS Stream, нас как компанию это не устраивает.
Спасибо. Да eBPF/XDP популярная тема, когда мы начинали этим заниматься, такое ощущение, что мы попали на пик популярности и буквально каждые пару недель выходила какая-то интересная статья. Начинали мы кстати с MVP на базе вот этого прекрасного кода от Netronome - https://github.com/Netronome/bpf-samples/ и еще пользовались вот этим - https://github.com/xdp-project/xdp-project
Все верно, это был один из запасных планов. Но тут стоит понимать, что даже если скажем общее capacity по нагрузке не поменялось, то скедулер ядра (я полагаю) может вести себя по разному при утилизации процессора в 80% и в 95% и вероятно это тоже может смазать картину.
Спасибо за ваш отзыв ) Что касается нашего впечатления об OL по сравнению с CentOS — очень бедные репозитории с пакетами, поэтому мы пытаемся использовать платные RHEL репозитории. Во всем остальном мы (engineering) разницы не заметили (кроме роста CPU :) ), а вот operations наоборот, насколько я понял, довольны регулярным выходом обновлений/патчей, каждый месяц (вроде бы так).
Ну если вы все таки подготовите честные бенчмарки и приоткроете завесу тайны, что же все таки там у вас под капотом это будет намного лучше, нежели голословное декларирование производительности вашего кода!
Однако с точки зрения моего опыта, DSP редко может обработать запрос за 2-3 мс. Расскажите, какие действия выполняет DSP при запросе, что он обрабатывается за 2-3 мс? Я не пытаюсь Вас закидать шапками, мне просто интересен Ваш опыт. Было бы очень любопытно посмотреть на Ваши бенчмарки!
— Повышенная произвдительность (до 2000 заявок в секунду в одном потоке, более 10 млн заявок в торговый день).
а чуть выше этого:
Теперь скорость обработки заявки в системе составляет от 500 микросекунд до 2 — это очень хороший результат. Общее время прохождения заявки от момента попадания в «Матрицу» до вывода ее в биржевые системы составляет от 2 до 5 миллисекунд
«от 500 микросекунд до 2» — это какой-то крайне дичайший результат, ибо на моем домашнем ноуте (достаточно старом) Intel Core 2 Duo 2.4 ГГц, сложение двух чисел в среднем занимает 8 микросекунд:
Теперь, если представить ваши вычисления на матрицах, ранг которых очевидно не два и не пять, то все элементы вряд ли поместятся в регистры процессора, а чтение из памяти в данном случае будет крайне дорогое, чтоб уместиться в
от 500 микросекунд до 2
, так что, мне кажется вы где-то немного ошибаетесь.
Возможно несколько наивный вопрос, я в этом абсолютный дилетант. Правильно ли я понимаю, что через каждые 25 секунд коннект рвется и заново инициируется скриптом?
Уважаемые, теме более полугода, все уже давно изменилось. Используйте появившиеся в uwsgi фичи, они прекрасно дружат с flask'ом, django и самим python'ом.
Уважаемый, а подскажите пожалуйста, чем вы профилировали нагрузку на систему (память, диски, проц, сеть)? Абсолютно не имею представления как это делается в windows.
Это как раз и есть тот колхоз, который мне бы не хотелось разводить в стартовых скриптах ) В данный момент, версия uWSGI 0.9.7.2 не позволяет использовать предложенный мной вариант, ведет себя аномально. Сейчас посматриваю в сторону Emperor.
Мне не хотелось колхозить стартовые скрипты для запуска на каждый django-проект, а запускать все традиционным для FreeBSD способом через rc.conf. Опять таки, уменьшить количество webapp.xml файлов, но это 10е, а то и 100е дело.
Если бы FreeBSD имела возможность запуска «управляется проект стандартным скриптом(projectname start|stop|reload)», то я бы выбрал его из соображений атомарности и автономности воркеров/проектов. Но FreeBSD не имеет такой возможности, поэтому я пренебрег этим.
Спасибо idle, FeNUMe, исправил Django-приложение, на Django-проект.
«Еще у вашего способа минус — если нужно перезапустить 1 проект, вы вместе с ним перезапустите остальные.» — Да, тут я с вами абсолютно согласен, но для решаемых мной задач это абсолютно не критично. Что касается способа запуска, который используется у вас, он как раз и является каноническим )
Вы возможно правы, с Django работаю исключительно как системный администратор, мне дают каталог с Django-приложением и говорят — «надо»! «Разные django-проекты на одном сайте?.. Смысл?» — а почему бы и нет? Отдельные задачи, отдельные Django-проекты.
Имеются в виду именно разные проекты — «конгломерат Django-приложений». Жаль что не написали, сэкономили бы мне время ) А содержимое location'ов nginx у вас такое же, или вы делаете как-то по другому?
# 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.
Естественно это справедливо только в ряде случаев.
reject_non_fqdn_helo_hostname — я бы это убрал, как показывает практика, многие администраторы почтовых серверов игнорируют соглашение об FQDN, к тому же в RFC описана передача hello в формате FQDN как should, а не must! Самый яркий пример в моей практике — Альфа-Банк. Во время сесси проверка делалась по 3м разным доменам — в hello один, в DNS другой, а в адресе отправителя третий — и ни один не был в формате FQDN.
RedHat анонсировало CentOS 8 как последнюю стабильную версию, которую они поддерживают и предлагают всем сфокусируется на CentOS Stream, нас как компанию это не устраивает.
Спасибо. Да eBPF/XDP популярная тема, когда мы начинали этим заниматься, такое ощущение, что мы попали на пик популярности и буквально каждые пару недель выходила какая-то интересная статья. Начинали мы кстати с MVP на базе вот этого прекрасного кода от Netronome - https://github.com/Netronome/bpf-samples/ и еще пользовались вот этим - https://github.com/xdp-project/xdp-project
Все верно, это был один из запасных планов. Но тут стоит понимать, что даже если скажем общее capacity по нагрузке не поменялось, то скедулер ядра (я полагаю) может вести себя по разному при утилизации процессора в 80% и в 95% и вероятно это тоже может смазать картину.
Спасибо за ваш отзыв ) Что касается нашего впечатления об OL по сравнению с CentOS — очень бедные репозитории с пакетами, поэтому мы пытаемся использовать платные RHEL репозитории. Во всем остальном мы (engineering) разницы не заметили (кроме роста CPU :) ), а вот operations наоборот, насколько я понял, довольны регулярным выходом обновлений/патчей, каждый месяц (вроде бы так).
Однако с точки зрения моего опыта, DSP редко может обработать запрос за 2-3 мс. Расскажите, какие действия выполняет DSP при запросе, что он обрабатывается за 2-3 мс? Я не пытаюсь Вас закидать шапками, мне просто интересен Ваш опыт. Было бы очень любопытно посмотреть на Ваши бенчмарки!
— имеем 7k запросов в 1 секунду (1000 миллисекунд) на один сервер с 6 ядами, за время отклика возьмем 10 миллисекунд, тогда:
7000 запросов * 10 миллисекунд / 1000 миллисекунд = 70 запросов должен обработать сервер за 1 миллисекунду
70 запросов / 6 ядер = 11 запросов каждое ядро должно обработать за 1 миллисекунду
Подскажите пожалуйста, где я ошибся?
а чуть выше этого:
«от 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}
Теперь, если представить ваши вычисления на матрицах, ранг которых очевидно не два и не пять, то все элементы вряд ли поместятся в регистры процессора, а чтение из памяти в данном случае будет крайне дорогое, чтоб уместиться в , так что, мне кажется вы где-то немного ошибаетесь.
Если бы FreeBSD имела возможность запуска «управляется проект стандартным скриптом(projectname start|stop|reload)», то я бы выбрал его из соображений атомарности и автономности воркеров/проектов. Но FreeBSD не имеет такой возможности, поэтому я пренебрег этим.
«Еще у вашего способа минус — если нужно перезапустить 1 проект, вы вместе с ним перезапустите остальные.» — Да, тут я с вами абсолютно согласен, но для решаемых мной задач это абсолютно не критично. Что касается способа запуска, который используется у вас, он как раз и является каноническим )
# 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.
Естественно это справедливо только в ряде случаев.