Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
И всё-таки я за то, что лучше бы вы сконтрибьютили в OpenResty, нежели вот такие велосипеды строить :) Было бы намного полезнее с точки зрения популяризации Lua ;)
mva, спасибо, тренд к Nginx конечно верный (и интересный) но "я не волшебник, я только учусь"… так что боюсь, рановато мне.
Предкомпиляция в lua — это профанация. Это скорее обфускация. Выигрыш, как было замечено, только на больших файлах, благодаря уменьшенному размеру файла.
Если нужна скорость и хочется именно lua, то надо делать nginx(фронтенд)+uwsgi(апп-сервер)+luajit.
Один из множества плюсов: использование легковесных lua корутин для многопоточности вместо создания нового lua state(по сути запуска отдельной lua машины) в apache/mod_lua.
Кстати при наличии luajit я вообще не вижу повода использовать стандартный lua интерпретатор.
Если нужна скорость и хочется именно lua, то надо делать nginx(фронтенд)+uwsgi(апп-сервер)+luajit.
Один из множества плюсов: использование легковесных lua корутин для многопоточности вместо создания нового lua state(по сути запуска отдельной lua машины) в apache/mod_lua.
Кстати при наличии luajit я вообще не вижу повода использовать стандартный lua интерпретатор.
про веб не скажу, но в целом jit сильно отстает от ванильной луа. в некоторых случаях это важно
Предкомпиляция в lua — это профанация. Это скорее обфускация. Выигрыш, как было замечено, только на больших файлах, благодаря уменьшенному размеру файла.
Позволю себе процитировать автора языка:
"Код в предкомпилированной форме не всегда меньше исходного кода, но он загружается быстрее"
Предкомпиляция маленьких файликов действительно часто давала файлы чуть большего размера, правда, существенной эту разницу назвать трудно.
Один из множества плюсов: использование легковесных lua корутин для многопоточности вместо создания нового lua state(по сути запуска отдельной lua машины) в apache/mod_lua.
Если не сложно, поделитесь опытом работы с Lua-корутинами.
А я, вот, не согласен с Вами по поводу того, что лучше NgX как фронтенд и uwsgi как апп-сервер.
Лучше NgX+mod_lua (кстати, в последней версии NgX научился в shared-модули) :)
— ну и кроме прочего — потому что у uwsgi каждый раз не угадаешь что поломали в новом релизе
(или в "apache/mod_lua" последнее относилось не к апачевому, а к NgX'овому? Если так, то там что-то такое было про инстанс на воркера. Ну и корутины работают (хотя я их не осилил :())
Лучше NgX+mod_lua (кстати, в последней версии NgX научился в shared-модули) :)
— ну и кроме прочего — потому что у uwsgi каждый раз не угадаешь что поломали в новом релизе
(или в "apache/mod_lua" последнее относилось не к апачевому, а к NgX'овому? Если так, то там что-то такое было про инстанс на воркера. Ну и корутины работают (хотя я их не осилил :())
Лучше NgX+mod_lua (кстати, в последней версии NgX научился в shared-модули) :)
Да так и попроще, на мой взгляд. Голосую за то, чтобы nginx вобрал в себя этот модуль и он был сразу "из коробки"
Ну и корутины работают (хотя я их не осилил :())
Если говорить о сопрограммах, доступных изнутри Lua, то я до сих пор не знаю, есть ли профит для обычного приложения в них. Например, в представленном фреймворке можно было бы каждый презентер сунуть в отдельную сопрограмму, но смысл…? Пока выполняется сопрограмма, основная программа-то стоит. Конечно, если скачивать файлы, или ещё что-то делать, "общаясь" с другими серверами, то выигрыш будет, а вот в обычном случае?
В LuaJIT string.dump или опция -b позволяет получить портабельный байткод, а это как минимум экономия на парсинге и построении ast.
Я не настоящий сварщик на самом деле, скорее проходил мимо lua и внимательно посмотрел.
Идея в следующем. Корутины в lua это такой дешевый и легкий механизм многопоточности(со своими граблями). Так вот uwsgi можно настроить так, что будет запускаться один инстанс lua машины(в случае luajit там полноценная машина с промежуточным байткодом и JIT) на процесс (мы запускаем по отдельному процессу на физический CPU). В свою очередь каждая lua-машина запускает единственное lua приложение, которое уже обрабатывает параллельные запросы.
В результате мы получаем очень мало накладных расходов при обработка параллельных запросов, а также всегда прогретый JIT. На синтетических тестах получается огромный выигрыш. Но все это надо, если у вас есть необходимость обслуживать десятки тысяч запросов.
В случае mod_lua есть разные варианты многопоточности, но по сути они все не такие красивые, как описаный выше вариант: нет возможности использовать одну lua-машину per-CPU для обработки параллельных запросов.
Tarantool от ребят из мейл.ру очень любопытный: они скрестили ежа с ужом. Они сделали помесь между апп сервером и in-ram storage engine, который чертовски хорошо параллелится с помощью тех же самых корутин.
Идея в следующем. Корутины в lua это такой дешевый и легкий механизм многопоточности(со своими граблями). Так вот uwsgi можно настроить так, что будет запускаться один инстанс lua машины(в случае luajit там полноценная машина с промежуточным байткодом и JIT) на процесс (мы запускаем по отдельному процессу на физический CPU). В свою очередь каждая lua-машина запускает единственное lua приложение, которое уже обрабатывает параллельные запросы.
В результате мы получаем очень мало накладных расходов при обработка параллельных запросов, а также всегда прогретый JIT. На синтетических тестах получается огромный выигрыш. Но все это надо, если у вас есть необходимость обслуживать десятки тысяч запросов.
В случае mod_lua есть разные варианты многопоточности, но по сути они все не такие красивые, как описаный выше вариант: нет возможности использовать одну lua-машину per-CPU для обработки параллельных запросов.
Tarantool от ребят из мейл.ру очень любопытный: они скрестили ежа с ужом. Они сделали помесь между апп сервером и in-ram storage engine, который чертовски хорошо параллелится с помощью тех же самых корутин.
m0sia, спасибо за развёрнутый ответ!
По поводу:
Какие варианты многопоточности считаете возможными и реальными?
Сам не пробовал Тарантул, но мысль запилить что-то внутри него на Lua была.
По поводу:
В случае mod_lua есть разные варианты многопоточности, но по сути они все не такие красивые, как описаный выше вариант: нет возможности использовать одну lua-машину per-CPU для обработки параллельных запросов.
Какие варианты многопоточности считаете возможными и реальными?
Tarantool от ребят из мейл.ру очень любопытный: они скрестили ежа с ужом. Они сделали помесь между апп сервером и in-ram storage engine, который чертовски хорошо параллелится с помощью тех же самых корутин.
Сам не пробовал Тарантул, но мысль запилить что-то внутри него на Lua была.
mod_lua я вообще не смотрел(только догадывался о его существовании). Apache для меня это такой вымирающий динозавр, который все никак не может отойти в мир иной.
На сайте modlua(http://www.modlua.org/gs/tweaking) они расписывают какие варианты многопоточность есть. Все вообщем-то достаточно гибко, но по сути всегда будут ограничения в лучших традиция apache: один thread на один request с одной lua-машиной.
PS я наткнулся на заметку "Хабр уже не торт" и решил написать комментарий, первый за много лет. :)
На сайте modlua(http://www.modlua.org/gs/tweaking) они расписывают какие варианты многопоточность есть. Все вообщем-то достаточно гибко, но по сути всегда будут ограничения в лучших традиция apache: один thread на один request с одной lua-машиной.
PS я наткнулся на заметку "Хабр уже не торт" и решил написать комментарий, первый за много лет. :)
mod_lua я вообще не смотрел(только догадывался о его существовании). Apache для меня это такой вымирающий динозавр, который все никак не может отойти в мир иной.
Моя идея была в том, что этот динозавр стоит на большинстве обычных хостингов, и если они с популярной нынче версии 2.2 перейдут на 2.4, то подключение mod_lua вообще не должно вызывать никаких затруднений. Мало того, такие хостеры должны были бы популяризовать Lua, т.к. сайт под его управлением не будет давать большую нагрузку, а значит, можно разместить больше сайтов на одном сервере и больше заработать. Но это ИМХО конечно, поскольку я сам не администратор, и нюансы хостеров не знаю.
PS я наткнулся на заметку «Хабр уже не торт» и решил написать комментарий, первый за много лет. :)
Лиха беда начало. А вообще, старые времена всегда "добрые", и трава тогда была зеленее. ))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Lua микро-фреймворк на Apache