не надо думать, что джанга простая для освоения новичкам, она наоборот, сложный комбайн, когда надо простую вещь реализовать

если только лезти против джанги

и не юзаю я его тоже по твоим же соображениям, что это монстр и для большинства задач явно избыточный

если не celery, то что?

да кончился уже холивар)

если не celery, то что?

я сейчас покажусь неоригинальным

но aiohttp

в некоторых случаях не нужен celery - можно просто засунуть таску в эвентлуп или запустить тут же в воркере рядом

а ты прям как я который был 5 лет назад и кричал что джанга монолитное гавно

а теперь ня?

в некоторых случаях не нужен celery - можно просто засунуть таску в эвентлуп или запустить тут же в воркере рядом

простенькая самописка?

простенькая самописка?

ну да, примитивный маленький сервис под не сильно большой нагрузкой

это уступки бывшим рубистам, которые только что осознали, что питон круче, и ноют, что в руби оно было

лол

да кончился уже холивар)

мне для себя интересно. особенно про асинхронщину

мне для себя интересно. особенно про асинхронщину

что именно про нее?)

вроде бы звучит все просто. много запросов обрабатывает параллельно и быстро. сделали дело, куда-то сложили или дали задание, отправили ответ.

но почему-то везде слышу асихронность асихронность асихронность

вроде бы звучит все просто. много запросов обрабатывает параллельно и быстро. сделали дело, куда-то сложили или дали задание, отправили ответ.

в контексте вебсервисов да

но это не только для вебсервисов

ты можешь с чем угодно асинхронно взаимодействовать - с девайсом через порт, например

или с процессом через потоки

еще интересный вопрос: tornado - это веб сервер полноценный/фреймворк/или что можно поставить за nginx или что-то еще? он много задач на себя берет

торнадо - скорее полноценный сервер

почитай про epoll/poll/select

ты можешь с чем угодно асинхронно взаимодействовать - с девайсом через порт, например

ну да. может просто как-то интервьюеру мой ответ не понравился.

как оно работает

торнадо - скорее полноценный сервер

его как фронт ставят? или все-равно за nginx?

ну да. может просто как-то интервьюеру мой ответ не понравился.

о, а что спрашивал?

его как фронт ставят? или все-равно за nginx?

просто запускают и все

nginx там не нужен, tornado по сути - во многом подобие nginx, только на питоне

смотри, говоря глобально, в чем суть асинхронных программ

у тебя есть программа и есть внешний мир

в простом случае ты из внешнего мира что-то забираешь, пропускаешь через код, выдаешь вывод

но что если ты хочешь в коде реагировать на определенные события из внешнего мира?

вот асинхронность как раз дает тебе такую возможность - ты подключаешься к событиям в системе, и “проматываешь” программу до следующего ожидания события

то есть, по сути, весь код становится event-driven

о, а что спрашивал?

блин. это еще в декабре было. спрашивали то вполне стандартные вопросы. про асинхронность было. отвечала про потоки, что при асихронности нет зависимости и блокировок. что ничего не висит.

блин. это еще в декабре было. спрашивали то вполне стандартные вопросы. про асинхронность было. отвечала про потоки, что при асихронности нет зависимости и блокировок. что ничего не висит.

потоки к асинхронности довольно слабое отношение имеют

если абстрактно, то можно дойти до всяких семафоров, процессов и диспетчеров

семафоры - это иэ области параллельности, а не асинхронности, в общем случае

ну, хотя я тут не совсем прав

nginx там не нужен, tornado по сути - во многом подобие nginx, только на питоне

просто боязно некоторые штуки оставлять открытыми наружу. звучит как manage.py run оставить на внешку

просто боязно некоторые штуки оставлять открытыми наружу. звучит как manage.py run оставить на внешку

manage.py run запускает однотредовый сервер, который годится только для отладки

а торнадо запускает epoll на сокете, который может асинхронно сотню тысяч коннектов держать

более того, wsgi и асинхронность дружат так себе

вот асинхронность как раз дает тебе такую возможность - ты подключаешься к событиям в системе, и “проматываешь” программу до следующего ожидания события

да. один из видов. так тот же GUI работает. и JS полностью пропитан этим (ибо веб страничка - вполне себе гуй). но в контексте веб серверов это не очень рулит. у нас есть 100500 запросов и нам моментально надо обслужить их и дать ответ. в каком-то роде событие. но тип - один.

поэтому запускать его под nginx смысла особо не имеет

да. один из видов. так тот же GUI работает. и JS полностью пропитан этим (ибо веб страничка - вполне себе гуй). но в контексте веб серверов это не очень рулит. у нас есть 100500 запросов и нам моментально надо обслужить их и дать ответ. в каком-то роде событие. но тип - один.

типа как минимум два - событие на чтение и событие на запись

а на самом деле больше

даже установка соединения - это событие

потоки к асинхронности довольно слабое отношение имеют

ну тот же nginx спаунит себе кучу процессов. чтобы обрабатывать их параллельно. а потом ось их еще раскидывает, ядер то много.

ну тот же nginx спаунит себе кучу процессов. чтобы обрабатывать их параллельно. а потом ось их еще раскидывает, ядер то много.

nginx вроде не спавнит процессы

это uwsgi спавнит, если его так настроить

более того, wsgi и асинхронность дружат так себе

wsgi вроде как стандартный интерфейс для питона.

nginx вроде не спавнит процессы

воркеры создает

ngnx же вроде как правило, статику раздает : )

апач тоже нынче форкается

а прочее уже веб серверы

типа uwsgi и gunicorn

wsgi вроде как стандартный интерфейс для питона.

да, но тем не менее

это uwsgi спавнит, если его так настроить

пока на сервере только php-fpm

а прочее уже веб серверы

ты все в кучу смешал :)

да(

uwsgi - не сервер

да, но тем не менее

тогда получается, что при асихронности мы выкидываем все старье типа джанги, фласка, которые работают через wsgi и берем модные торнадо и ioaync'и? где уже свои веб сервера?

Блин, а как это называется?:D

Всем привет. Дико нубский вопрос, но что-то уже туплю. Есть один скрипт, который создает файл. Необходимо сделать так, чтобы этот файл создавался рядом с исполняемым файлом, а не в директории, относительно которой запускается интерпретатор. Как это сделать на баше в одну строку?

Блин, а как это называется?:D

если совсем корректно - то это просто демон, имплементирующий wsgi-протокол

если совсем корректно - то это просто демон, имплементирующий wsgi-протокол

но его потом проксируют?

uWSGI application server container

ERROR: S client not available

Всем привет. Дико нубский вопрос, но что-то уже туплю. Есть один скрипт, который создает файл. Необходимо сделать так, чтобы этот файл создавался рядом с исполняемым файлом, а не в директории, относительно которой запускается интерпретатор. Как это сделать на баше в одну строку?

на баше? не на питоне?

но его потом проксируют?

кого проксируют? проксирует nginx, он как раз использует WSGI, чтобы запрос прокинуть через uwsgi в wsgi-приложение питоновское

на баше? не на питоне?

На баше нужно написать маленький скрпт, который будет запускать python-скрипт так, чтобы файлы создавались в директории со скриптом, будто интерпретатор вызывается относительно этой директории.

uwsgi общается с питоном через wsgi. создает сокет, по которому общается с nginx. и есть подозрение, что там http. а тогда это проксирование уже

uwsgi общается с питоном через wsgi. создает сокет, по которому общается с nginx. и есть подозрение, что там http. а тогда это проксирование уже

там не http, там wsgi

wsgi - это протокол

На баше нужно написать маленький скрпт, который будет запускать python-скрипт так, чтобы файлы создавались в директории со скриптом, будто интерпретатор вызывается относительно этой директории.

файлы создаются из питоноскрипта или из баша?

если из баша - всегда есть pwd

если из питона - тогда можно использовать os.path.dirname(__file__)

про баш соврал немного - там все извращеннее, вот тут есть обсуждение - https://stackoverflow.com/questions/59895/getting-the-source-directory-of-a-bash-script-from-within

там не http, там wsgi

возникает вопрос. если по обеим стороным wsgi - нафига демон uwsgi нужен?

возникает вопрос. если по обеим стороным wsgi - нафига демон uwsgi нужен?

потому что сишная реализация протокола быстрее питоновской?

можно вместо uwsgi взять gunicorn

возникает вопрос. если по обеим стороным wsgi - нафига демон uwsgi нужен?

nginx не по wsgi а по uwsgi

будет медленнее сильно

nginx не по wsgi а по uwsgi

не надо путать

нафига gunicorn если uwgi шустрее и еще много чего может

wsgi - протокол, uwsgi - конкретная его реализация

которая есть в виде модуля в nginx

посмотрите в доках

protocol = uwsgi

нафига gunicorn если uwgi шустрее и еще много чего может

gunicorn, например, умеет в gevent-воркеры

gunicorn, например, умеет в gevent-воркеры

uwsgi тоже

uwsgi тоже

разве? каким образом, интересно?

кроме этого еще овердофига всего. заменить celery или rq и много много другого

protocol = uwsgi

хорошо, согласен в этом случае - https://uwsgi-docs.readthedocs.io/en/latest/Protocol.html

которая есть в виде модуля в nginx

uwsgi демон - часть nginx? О_о

UWSGI_PROFILE=gevent pip install uwsgi и юзай в конфиге настройки для запуска с гевент

uwsgi демон - часть nginx? О_о

реализация протокола на стороне nginx же тоже нужна

UWSGI_PROFILE=gevent pip install uwsgi и юзай в конфиге настройки для запуска с гевент

это странно, но окей

реализация протокола на стороне nginx же тоже нужна

а что там на стороне nginx? тот же wsgi, только уже сишный демон общается?

ничего странного