Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LuaJIT NYI codes #5

Open
moonbingbing opened this issue Sep 13, 2016 · 6 comments
Open

LuaJIT NYI codes #5

moonbingbing opened this issue Sep 13, 2016 · 6 comments

Comments

@moonbingbing
Copy link

@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")
    ';
@moonbingbing
Copy link
Author

moonbingbing commented Sep 13, 2016

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

@sumory
Copy link
Contributor

sumory commented Sep 13, 2016

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

@moonbingbing
Copy link
Author

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?

@sumory
Copy link
Contributor

sumory commented Sep 13, 2016

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.

@sumory
Copy link
Contributor

sumory commented Sep 13, 2016

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.

@ms2008
Copy link

ms2008 commented Sep 13, 2016

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants