iresty / Mio

API statistics/summary and health datas in NGINX based on OpenResty/ngx_lua, just like NGINX Plus

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

LuaJIT NYI codes

moonbingbing opened this issue · comments

@sumory there are some codes in Lor can not be compiled by LuaJIT.

attachment 1.txt is generated by jit.dump. You can use like this:

init_by_lua '
        local v = require "jit.v"
        v.on("/tmp/jit.log")
    ';

this tool https://github.com/agentzh/nginx-devel-utils/blob/master/ljbc.lua can explain bytecode 51. for example:

$ /usr/local/openresty/luajit/bin/luajit-2.1.0-alpha ljbc.lua 51
    opcode 51:
    FNEW

that's means new a function.

other bytecode numbers are also this method

i'll try to make some improvement about these performance issues in the next main version of lor. :)

I will try to generate flame graph to find more performance issues.
by the way, if we have thousands of locations, can the router of lor handle them quickly like NGINX?

Unfortunately, lor is not as fast as Nginx when handling thousands of locations.

  • the locations(uri) are organized as a pipeline with a stack/array structure.
  • every request will pass through this pipeline to find middlewares that are adapted to it.
  • this feature is powerful for business logic like some other frameworks do(such as express) , however it's also a tradeoff with lower performance.
  • as a result for test, the Hello World test case for Nginx/OpenResty is 2x faster than lor. however it's still hard to design a meaningful and reasonable test case cause lor will process several steps while Nginx only performs ngx.say("hello world").
  • no more specific test cases were performed.

Currently, we can improve the performance with these measures:

  • local app = lor(), init routes and middlewares with lor in a separate lua module, and then invoke app:run() in the main endpoint.
  • if we exactly know when to exit this request, we should invoke the response methods(res:json/res:text/res:render...) as soon as possible.

another possible and effective way to optimize is to separate app initialization to init_by_lua block. but it's such a big change for the architecture of this framework and use experience for developers. maybe i will have a try on it with more tests.

@moonbingbing I had did this test before.

  1. lor performance optimization trick

I don't think it's a problem that the lor should as fast as the original ngx_lua. It's like wheels run fast then the car, but it is useless if without any seats. Isn't it?