Pull to refresh

Comments 35

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

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

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

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

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

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

Kong так то — на том же openresty и написан.
Все там можно. просто надо будет нырнуть в его АПИ.

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

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

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

1) вариантов много, самый простой в файле на Lua
2) pgmoon?
UFO just landed and posted this here
> именно поэтому, к примеру, в nginx нет классического cgi-интерфейса

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

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

Вот еще просто Иисусий фреймворк http://leafo.net/lapis/, пилится одним человеком, но как же он круто работает…
Так то он — надстройка на openresty.
moonscript — сомнительно. Есть как плюсы так и минусы
Игровой движок называется 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 тоже используется, но до состояния, когда на нём будет написана существенная часть инфраструктуры ещё очень далеко…
Упоминание highload и apache в одном контексте меня каждый раз смущает…
Ну и далее по тексту ;)

Смотрят же от загрузки, от профилирования, от ресурсов и так далее. Вы вот говорите, что основная нагрузка от пользовательского кода, поэтому веб-сервер неважен, ну так это же не у всех так.
да, у Луа довольно низкий порог вхождения, но… можно порой голову сломать с прототипным наследованиям через метатаблицы, переопределением операторов, одновременным хранением числовых и строковых индексов, отсутствием исключений и паскаль подобным синтаксисом…
Интересный факт, Lua изначально создан как формат конфигурационных скриптов. Отсюда такой интересный синтаксис. Чья безумная мысль породила метатаблицы метатаблиц метатаблиц — не скажу…
Исключения отсутствуют, но наличествует «безопасный вызов функций» через pcall/xpcall, можно использовать вместо исключений. Ну, и изначально писать чистый код через фильтрацию нежелательных случаев.
… услышал, что на Lua написан только Tarantool. Это не так, на Lua много чего написано. Примеры: OpenResty, XMPP-сервер Prosody, игровой движок Love2D, Lua скриптуется в Warcraft и в других местах.
Вот ещё пример для встраиваемых систем — Barracuda Application Server и основанный на нем Mako Server. Позиционируется как «RTOS Ready Embedded Web Server on Steroids» использует Lua Server Pages (LSP)
Еще torch.ch

Asterisk, Kamailio, Freeswitch Используют lua Как встраиваемый язык.
Есть еще NodeMCU — крутая платформа для ESP8266 c кучей библиотек.
Из игровых движков юзал Corona SDK — как по мне более интересное решение, нежели Love2D. Есть встроенный эмулятор, удобная облачная сборка, пакеты распространяются через магазин (тебе даже тянуть ничего не нужно — нажал «установить» в магазине и profit!
Sign up to leave a comment.

Articles