Hey All.. I have been playing around with serverless cfml (based on the fuseless project) and wanted some constructive feedback on the structure of this small sample app.. it's intended to be super lightweight. I'm mainly wondering about the organisation of the components, naming conventions and if I'm instantiating the

services.utils

component in the Application.cfc in the most acceptable way.. and whether this pattern would be acceptable for the other components eg: main.cfc https://github.com/chapmandu/serverless-cfml/blob/master/functions/greeter/cfml/app/Application.cfc#L10

works either way TBH, creating them is pretty darn quick, it's only if you aren't using them that much then it becomes more overhead, i.e. lazy load when required, but this is probably splitting hairs over a few ms

yep its not a huge worry, but with serverless it is generally better to lazy load components as needed because every time you get a new lambda container (eg every hour or so, or if there are simultaneous requests) then it has to recompile your cfml into java bytecode. That would only be a consideration however if there the lambda does different types of tasks, if it is doing the same thing every time you execute it, then probably not worth worrying about. Generally though I wouldn’t worry about it unless you are building something front facing with it, for a backend task it is not going to add up to much

@foundeo Have you tried pre compiling a fuseless app? I'd be interested to see if there were any performance gain there..

I second what Pete suggested, there are way to keep the lambdas warm ( periodic pinging ). but you have to remember that AWS can recycle the lambda and you can get cold start even when pinging. Also understand that if there are 2 concurrent requests ( eg your process takes 5 seconds to run and you call it 5 times ) you will have 5 instances of that lambda started and then 5 warm.

I made this commandbox command: https://github.com/foundeo/cfml-compiler for that purpose, you can just replace your cfm/cfc files with a pre-compiled version on lucee but I haven’t had a chance to measure if it makes much difference.

yeah mate.. I've used that with great success before.. was just wondering if you'd tried it with fuseless apps.. I'll try to implement it unless you beat me to it.. I don't have the performance monitoring setup though..

go for it, would love to see what you can find… pretty good metrics in the lambda dashboard you can use

my experience with precompiled .lars is they are slightly slower. Theorectically can achieve the same result (precompiled) by running your app once and saving the state and setting inspect templates to none

Interesting.. i haven't used a .lar file (not sure if it makes any difference).. I've just replaced the cfc/cfm files with their pre-compiled versions.. Is there an env variable I can use the inspect_template="never" ?

dunno, have a look at the docs https://docs.lucee.org/guides/Various/system-properties.html

Similar shape with more complex code.. just the execution times are higher

How did you run the test @chapmandu? Did you deploy this 3 seperate time? Did you try with Provisioned concurrency and a variety of memoery settings?

Hey @paul.. I deployed 3 separate times with 1 request per second..

Try with over 3.5 g Ram the same test

I'll give it a go.. thanks mate

Yeah, it’s good. There is a decent cfml library aswell. That I am not sure how performance the credentials part of it is, from memory it try's to get auth on every request. Which involved a http call

Which cfml library is that?

This goes down to how Java treats strings. In Java, a string is an object, whereas every other language is a primitive data type. Unless you are doing some crazy stuff with your data, there is literally zero performance gain to be made. If anything, when you force the ColdFusion engine to then look at compiled bit code, it has to hammer several other libraries, uncompress the code, then figure out what to do with it. The only cavet to this might of been BlueDragon, but lets face it, that died like common sense.