Reduced load time

[marcelobern]

@pimterry as I experienced lambda-git load times of up to 7 secs @ 128MB, I have been looking for alternate ways to have lambda-git work so we can reduce its load time.

Wanted to check if you have any similar work underway.

If not, would you want me to open a PR in case I get anywhere?

[pimterry]

@marcelobern no, I'm not working on that. I'd definitely be open to pull requests if you have a way to speed things up.

[marcelobern]

@pimterry will do.

BTW, I submitted a PR for serverless and lambda-git is in there ;-)

[marcelobern]

@pimterry here is the first result of running the new and existing codes (not a proper performance comparison though).

Existing code (initial run):

314d0872-d572-11e8-a157-6d279cbe4e9b { status: 'lambda-git: loaded' }
Duration: 4869.99 ms Billed Duration: 4900 ms Memory Size: 128 MB Max Memory Used: 45 MB

Existing code (subsequent run):

519d4717-d572-11e8-bb59-df8701e3c6ac { status: 'lambda-git: already loaded' }
Duration: 0.69 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 46 MB

New code (initial run):

5c96a4bf-d570-11e8-b46f-212ccdc20a1b { status: 'lambda-git: loaded' }
Duration: 2449.90 ms Billed Duration: 2500 ms Memory Size: 128 MB Max Memory Used: 29 MB

New code (subsequent run):

72b5f226-d570-11e8-bb41-77fbb4a850ec { status: 'lambda-git: already loaded' }
Duration: 10.40 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 29 MB

I will work on cleaning up the code and looking into some better performance comparison for us to check if we can sustain this 49% reduction in run time ;-)

Cheers!

[marcelobern]

@pimterry through a lambci thread we have access to a git 2.13.5 tar file.

Please let me know if you would like me to go ahead and slap git 2.13.5 to the PR or if you prefer to have it stay @ 2.4.3

[pimterry]

That all sounds excellent! Where does that performance improvement come from?

Regardless, I would love to see a PR with those changes so I can take a look and get this in. Updating to a newer build of git too sounds great to me 👍.

[marcelobern]

@pimterry great, will do!

The performance improvement comes from a little "sleight of hands". Rather than untar at runtime, that is all done before packaging lambda-git. We than have to solve the problem of size of the package (i.e. get rid of "duplicate" files), which is where I have been focusing my effort.

At runtime we then just re-create the original file structure with links, which are much faster to create that the current untar approach. BTW, I already tested it with the newer git 2.13.5 and it worked perfectly as well! So we should be able to upgrade git in a straight forward way from now on ;-)

I have been tinkering with the runtime code to optimize it and my results last night (using artillery for testing at "scale") show a load time of 900-1300 ms using link creation versus 7300-9700ms using the untar approach. That was for a lambda with 128MB RAM.

As for the PR, I believe it is worth packaging this link based approach on its own then folks with need for other binaries can benefit from it as well. So I am in the process of creating a new npm package and will submit the lambda-git PR using this npm package. This will make the change to lambda-git minimal.

[pimterry]

Very neat, that makes sense. Very nice work, I'm looking forward to the PR 👍

[marcelobern]

@pimterry I am about 95% done with the PR.

As I ran the test, the second test Should install the Git binary to a given directory fails.

I am not familiar with bats so after a few hours of checking code and the test case I decided to run the same test cases using mocha/chai and they all pass.

Please let me know if you have any suggestions on how you would like me to proceed.

In the mean time feel free to check the new modules I will be using:

• bin-minify
• lambda-bin

[pimterry]

Great! The test issue is surprising though. Bats is very simple, and it really shouldn't break unless something has changed. Once you've got everything else working, can you push the code & failing bats tests to a branch somewhere, so I can take a look?

I'm definitely open to converting them to something more substantial like Mocha & Chai, but I'd just like to know why they're failing first, so we can confirm the failure isn't actually a real problem.

[marcelobern]

@pimterry code is ready for the PR (except for the bats testing).

You can check what is going on in Travis CI. Some of the failures are bats related some are compatibility issues.

Please let me know if you want me to start the PR as is or if you have any additional suggestions/asks.

BTW, you can run the performance benchmark yourself if you want to ;-)

Have a great week!

[marcelobern]

OK, bats testing is now:

• Working for Node 6-9
• Failing for Node 4 & 5 in all test cases - I am not overly concerned as these Node versions are no longer supported. Your take?
• Failing only test case # 3 for Node 10 & 11 - even though I inspected and the variables are in there

Will give it another go tomorrow but if I cannot figure it out I will submit the PR as is (unless I hear something else from you).

[pimterry]

All sounds very promising. Yes, if the code is anywhere near ready to review, you should definitely open a PR, and we can discuss details from there.

On the specifics:

• Very happy to drop support for Node 4 & 5.
• We do need to work out what's up with Node 10 & 11 though, and fix that (or fix the tests).

[marcelobern]

Submitted PR #13.

I ended up changing default test from bats to mocha before the PR, as mocha tests are passing while bats is failing for Nodejs 10 & 11 (test case 3 only).

And by moving to mocha we now have code coverage information as well ;-)

Please add coveralls to the repo so the coveralls badge in README.md will work.