В моем сознании всплывает нечто среднее между «Круто» и «Зачем?».
По выступлению пара шутеечек почти зашла (на самом деле нет). Но по существу идея реально крайне интересная. Сейчас как раз думаем над задачей возможности передачи в nginx состояния авторизации пользователя от рельсового приложения для решения одной нестандартной задачи и эта статья попалась на глаза как нельзя кстати.

Мы сначала так и делали. Теперь авторизация происходит на стороне nginx и до медленной rails далеко не всегда дело доходит. Более того, все JSON APIs уже изначально на Lua пишутся.

Мне почему-то такая же идея в голову пришла и я написал auth proxy. Работает корректно. Из минусов сравнительное неудобство тестирования (хотя привыкаешь), отсутствие централизованной инфраструктуры lua/C и индексы массива начинающиеся с единицы. В остальном очень комфортно.

У нас полноценные интеграционные тесты через lapis написаны. Только одно неудобство, нельзя stub-ить код в другом процессе :)

Для таких велосипедов есть хороший фреймворк для Gateway API — Kong с плагинами и всё это на Lua.

Kong для проксирования api, не стоит его сравнивать с полноценным сервером приложений.

Также не стоит забывать про lapis

Еще сюда же можно добавить luvit – node.js только на lua.

Меня отпугивает подход luvit к асинхронным операциям, очень не люблю callback-и. Но несомненно проект достоин внимания. Кстати есть ещё и cqueues, у нас на нём web UI роутера крутится. Он отличается более тонким контролем event-loop и сильно гибче nginx.

Два вопроса. Предположим, делается REST сервер.
1) Где и как хранить конфигурационные файлы приложения.
2) Что надо сделать, чтобы пользоваться не MySQL, а PostgreSQL ?

1) вариантов много, самый простой в файле на Lua
2) pgmoon?
У nginx асинхронная неблокирующая архитектура и нужно избегать тяжелых процессов в обработчиках запросов (именно поэтому, к примеру, в nginx нет классического cgi-интерфейса, только fcgi и uwsgi), в связи с этим вопрос: когда выполняется запрос к БД через db:query, worker/интерпретатор тупо ждет, или там там какой-то свой хитрый event-loop (вариант что плодятся отдельные треды я уж не рассматриваю)?
> именно поэтому, к примеру, в nginx нет классического cgi-интерфейса

Скорее из-за принципов и особенностей мышления разработчика. Создавать по запросу cgi-процессы и работать с ними асинхронно через sdtio — не такая уж и сложная задача. Для простых «одноразовых» задач, навроде обновления конфига через веб-интерфейс, нет смысла поднимать fcgi-сервер. Поэтому lighttpd

Все операции с TCP/UDP сокетами неблокирующие. Т.е. да, там используется event-loop nginx-а, чтобы ждать ответ от DB.

Вот еще просто Иисусий фреймворк http://leafo.net/lapis/, пилится одним человеком, но как же он круто работает…
Игровой движок называется Love2D, а не Lua 2D

Мы используем у себя опенрести для кучи задач:
Статистика
Детект мобильных девайсов ( https://github.com/isage/lua-resty-mobile )
Блочный кеш (через ssi) в редисе
Ресайз картинок на cdn ( https://github.com/isage/lua-imagick )
Сейчас медленно и неторопливо пилю либу для монгодб (хранить метаданные тех же картинок) ( https://github.com/isage/lua-resty-moongoo )

Минус в том, что OpenResty-сообщество в основном китайско-говорящее и общающееся на англицком через google translate.
Стоило еще упомянуть в статье, что изначально ngx_lua был разработан в taobao, а после поддерживался/поддерживается cloudflare (куда ушел работать автор)

Он уже ушёл и из cludflare тоже :)

Упоминание highload и скриптовых либо VM-языков в одном контексте меня каждый раз смущает. Если это действительно Highload — время на переключение, очистку контекста и GC, не говоря уже о дополнительном времени, которое теряется в рантайм-обёртках этих языков капает в приличные цифры и приличные суммы. Не даром всякие мордокниги и контакты давно перевелись на компилируемые языки.

ИМХО, настоящий хайлоад это только компилируемые языки без VM, и чем тоньше обёртка между языком и железом — тем лучше. Только хардкор. Тем более, на С++ или Rust нынче можно создать вполне дуракоустойчивый и простой API для серверных программистов классом ниже.

Мы вот в своё время выбрали старый добрый Apache Httpd вместо nginx. Ключевые причины — богатый API и быстрая + дуракоустойчивая система пулов памяти. Если основная доля работы выполняется пользовательским кодом — асинхронный ввод-вывод nginx вдруг перестаёт приносить существенный прирост производительности. Ещё один важный момент — падение одного воркера апача от какого-нибудь неизбежного в С++ SIGSEGV создаёт меньше проблем, чем падение nginx.

P.S. Конечно, стоит признать, лучше LuaJIT для указанной в статье цели ничего нет. Если не использовать ничего компилируемого.
ИМХО, настоящий хайлоад это только компилируемые языки без VM, и чем тоньше обёртка между языком и железом — тем лучше.
В соответствии с вашими определениями вот это вот — highload (reddit-эффект форум выдержал и даже не поперхнулся), а вот это вот — нет (миллиард пользователей и петабайты данных? это неважно: там Java, а значит это — «ненастоящий» highload).
А если бы там изначально вместо Java использовать нечто компилируемое — сколько бы ресурсов железа это сэкономило?

Это да. Вопрос в том, когда бы оно было разработано, во сколько бы обошлась разработка нинзя-отрядом матёрых С++ разработчиков это всё. Для не самой концептуально сложной Джавы хорошие программисты стоят не дешево, а уж для плюсов… я даже не знаю, есть ли такие люди среди нас.


Ну и еще большой вопрос, насколько оно быстрее бы вышло грамотно настроенного netty. Смущают разве что паузы GC.


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

Тем не менее, критические части инфраструктуры, как правило, пишутся дорогостоящими специалистами на компилируемых языках. Просто потому, что без этого — дороже. И, по-моему, именно это делает хайлоад способным к, собственно, хайлоаду.
Да ладно вам. Hadoop — это типичнейший highload. А там — голимая Java.

Переписывать на компилируемые языки — дороже будет…
Кроме того, мне казалось, критические по ресурсам части инфраструктуры Google давно переписаны под Go, разве нет?
Конкретно GMail — по-прежнему в основном Java. Поиск — это в основном C++. Go тоже используется, но до состояния, когда на нём будет написана существенная часть инфраструктуры ещё очень далеко…
да, у Луа довольно низкий порог вхождения, но… можно порой голову сломать с прототипным наследованиям через метатаблицы, переопределением операторов, одновременным хранением числовых и строковых индексов, отсутствием исключений и паскаль подобным синтаксисом…
Интересный факт, Lua изначально создан как формат конфигурационных скриптов. Отсюда такой интересный синтаксис. Чья безумная мысль породила метатаблицы метатаблиц метатаблиц — не скажу…
Только зарегистрированные пользователи могут оставлять комментарии.
Войдите, пожалуйста.