-
-
Notifications
You must be signed in to change notification settings - Fork 375
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
Perfomance issue #78
Comments
I've done some research. Looks like
This will save execution time by not loading any other middlewares and still pretty handy and comfortable way to get middleware. What do you think? |
I was thinking about this the other day as well. We want to include only the code required for a given lambda to run. We can optimize in two places
You can solve this in userland with We could have middleware published as separate packages with a tool like https://lernajs.io/ (or the new packaging tool the lerna creator is close to finishing) So a user would install the lean core and only the middleware they need.
This would keep the zip as tiny as possible. The repo can stay a monorepo, it's just a change to how the middleware would get published to npm via lerna |
Agree with @DavidWells 👍 This is a perfect case for setup much like Babel has. One monorepo and complementary packages under |
Very good points from @NPCRUS and @DavidWells. The current architecture (and examples) are definitely helpful in terms of performance when using the bundled middlewares. I like the options of using a mono-repo approach and separate the middlewares from the main core, so this might be something to consider for the near future, maybe targeting the first stable 1.0.0 release. At the moment there's a very easy fix anyway, you can import middlewares directly as follows: // imports only one middleware (doNotWaitForEmptyEventLoop)
const doNotWaitForEmptyEventLoop = require('middy/src/middlewares/doNotWaitForEmptyEventLoop') This should do, until we figure out how to switch to a mono-repo approach. Comments/thoughts? |
Also, @vladgolubev, I really like the idea of having scoped package as babel. we might have the following approach: const middy = require('@middy/middy') // or '@middy/core' or simply 'middy'
const doNotWaitForEmptyEventLoop = require('@middy/doNotWaitForEmptyEventLoop') |
Hey @lmammino any update about the approach you guys would prefer ? |
Hello @kevinrambaud 😉 const doNotWaitForEmptyEventLoop = require('middy/src/middlewares/doNotWaitForEmptyEventLoop') Moving towards a more stable |
if you need any help, I would highly be interested to contribute 😁 |
Definitely, all help is appreciated. I'll try to lay out a roadmap for 1.0.0, meanwhile, being an open source project, every area you feel needs an improvement, is probably something that deserves a PR or a discussion, so feel free to make your own suggestions 😉 |
It'd be prudent to update your documentation to include this workaround. |
Hello @karlbateman, would you like to submit a PR for that? |
@lmammino Will do 👍 |
Awesome, i look forward to seeing your PR :) |
Closing, v1-beta is now out with mono-repo support. |
I found, that such code:
const { doNotWaitForEmptyEventLoop } = require('middy/middlewares')
or actually importing any middleware, and any amount of it adds aditional 110 +-5 ms to code execution
My lambda without adding any middlewares running approximately 35-40 seconds. And if I want to add some middleware from you library, it becomes 110 ms seconds more. In case of high availability microservices it's not really good.
BTW middy itself without attaching any existed in library middlewares works fine.
Do you have any idea, how to solve this?
Best regards
P.S: the way you can test it:
The text was updated successfully, but these errors were encountered: