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

Но у нас же не прода.

в наших конфигурациях вообще нет необходимости перезагружать сервис при изменениях, спасибо lua за эту возможность.

У вас отключено кеширование луа? Это замедляет исполнение луа-скриптов примерно в ~1000 раз.

у нас включено кэширование lua скриптов

Тогда как вы не перезагружаете конфиг, но изменяете луа часть? Очищаете package.loaded по внешнему сигналу, и либы типа перезагружены?

А, ну нормась. А если надо изменить луа-часть, то что? : )

Или там параметры по типу кусков кода, который потом loadstring'ается?

такое было два раза за год, стараемся делать так что бы не было лишних причин перезагружать сервисы, лучше когда lua получает данные извне. Это типа API которое можно настроить натыкав галочки в админке что написана на php или Java, это удобней чем постоянно передергивать сервис

Так, допустим у вас появляется новое API. Нужна новая команда, которая делает что-то новое. Как вы её добавляете?

Или луа типа запихивает запрос и данные с новой командой в redis, приложение на php или java — читает её из редиса, делает бизнес-логику, записывает ответ обратно в redis, и луа-часть ждёт пока в редисе не появится ответ и выдаёт результат?

Ну в общем понятно, у вас луа исполняет фронт-часть, типа чисто набор маленьких скриптиков которые делают предельно тупую работу ввода/вывода контента, а основная логика в жава-приложениях. Я-то уж подумал что вы делали бизнес-логику на самой луа, и каким-то образом не перезагружали конфиг. Если что, на луа действительно можно делать бизнес-логику. И даже не перезагружать : )

Хмм, а как выглядит запрос-ответ? Нгинксу пришёл запрос, надо что-то посчитать/вычислить. Он передал его луа. Луа записала в бд: "появился запрос такой-то с такими-то данными". Его обрабатывают и что-то возвращают в редис. Что в это время делает луа? Запрос-то как бы ещё не прерван.

Нене, я спрашиваю про простую штуку: процесс запроса. Нгинкс не будет дёргать луа по причине появления новой записи в бд, но он принимает запросы и должен что-то возвращать. Это база протокола HTTP: принял запрос, выдал ответ.

lua не ходит у нас в БД, обращение к диску занимает много времени, lua ходит в ОЗУ

Redis это БД. In-memory DB.

Ладно, сформулируем чуть иначе: Нгинксу приходит запрос. Он передаёт его в луа, луа передаёт его в In-memory-DB Redis. Сервисы которые снуют вокруг смотрят: опа, в In-memory-DB Redis появился новый запрос. Считают-вычисляют всякую фигню, в это время Lua-машина ждёт пока что-то не придёт обратно в In-memory-DB Redis, считывает оттуда и возвращает клиентской стороне то что считала, так?

за 40 строк расстрел солеными огурцами с занесением в личное дело

за 40 строк расстрел солеными огурцами с занесением в личное дело

А хлеб дают с огурцами? А так вполне хорошо звучит. Как насчёт сервисов с авторизацией?

Запись запроса в In-memory-DB Redis и ожидание ответа из неё можно уложить в десять строк. Это предельно простая задача без всякой логики. Пофигу кто решит этот запрос, в каком контейнере или без него, на каком языке и так далее, если ответ появился в In-memory-DB Redis — его можно вернуть. Луа стороне надо по HTTP вернуть ответ. Откуда она его берёт?

за 40 строк расстрел солеными огурцами с занесением в личное дело

lua решает кейсы на протяжении всех фаз жизненного цикла запроса, у нас есть такие кейсы когда в течении запроса подключаются 10-15 lua скриптов в процессе выполнения запроса юзера

по мне так это глупости мерить что-то кол-вом строк и делать на основе этого оценку

lua решает кейсы на протяжении всех фаз жизненного цикла запроса, у нас есть такие кейсы когда в течении запроса подключаются 10-15 lua скриптов в процессе выполнения запроса юзера

"Луа стороне надо по HTTP вернуть ответ. Откуда она его берёт?"

lua не только надо вернуть ответ в браузер но и еще добавить заголовков, в body добавить данных при определенных условиях, и в куках еще для некоторых наследить, lua контролирует все фазы жизни запроса в nginx

Вопрос не о том "что она ещё делает", а о конкретной вещи, откуда она берёт посчитанный ответ. И ждёт ли она пока этот ответ не появится (потому что что-то надо вернуть).

Допустим, код location'а: (это типа псевдокод, но суть должна быть понятна) location /api/.* { content_by_lua_block { -- записали запрос redis:set("request_12345", ngx.req.body) -- если мы читаем ответ из redis'а же -- нам надо подождать пока не появится ответ, -- он хз когда прилетит local response = redis:get("response_12345") while not response do response = redis:get("response_12345") end ngx.say(response) } } Она читает из редиски ответ, который там появится когда какой-нибудь сервис решит этот запрос? Ждёт пока ответ не вернётся или выдаёт заглушку: "обратитесь позже, когда ответ будет готов", заставляя жаваскрипт бомбардировать сервер запросами "мы уже приехали?" или ещё как?

В цикле такая: "Есть чо? А сейчас есть чо? Мы уже приехали?"? Надо же что-то ответить.

Почему? Нгинкс способен обрабатывать миллионы одновременных запросов. Если боишься перегрузить In-memory DB Redis — добавь sleep в цикле.

Sleep из нгинкса заставляет нгинкс делать то же самое. Переключаться к другому запросу, делать другие дела.

nginx ничего не делает сам, делают всю грязную работу его рабочие worker process

Ох. Когда ты пишешь ngx.sleep(0.2), воркер-процесс начинает делать другой запрос. Но это не важно. Важно "Начинает Делать Другой Запрос" Другой запрос. Запрос, другой. Он не простаивает, он занимается полезным делом, выполняет другой запрос. Потом возвращается обратно к этому, когда время истечёт. Но пока не истекло, делает другой запрос.

Ладно, мне лень ещё час допытываться, буду считать что вы делаете это не лонг-поллингом (длительные запросы) а простым поллингом (частые запросы). Если что, лонг-поллинг быстрее: не надо постоянно открывать/закрывать соединения, это медленный процесс. И нагрузка на сервер меньше (хоть и памяти обычно нужно чуть больше). Sleep хорош даже в гнинксе (местная вариация слипа).

Если у тебя секретность, и нельзя говорить другим о "методике ваших запрос-ответов" — так и скажи, меньше будешь мучать людей. Если сам не в курсе о том как происходят дела — лучше тоже скажи что секретность, самолюбие на месте, и от тебя отстали.

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

Ну хорошо, твой ответ в двух словах всё ещё не то что я спрашивал, но ладно, тогда подожду : )