AWS will likely add PHP support, yes but they absolutely will not do what this project does: Running a NodeJS http server that launches a PHP binary and runs local scripts.

That's just one way to make it happen until we get proper support. I wrote to AWS support and they said that they will consider PHP support for AWS lamba as many people have requested it too (did not give me an ETA though).

The funny thing is the response time is quite good despite running it through a NodeJS server that launches a PHP binary (340ms, faster than 98% of the sites as per pingdom[1]).

[1] https://tools.pingdom.com/#!/ex9izm/https://www.lambdaphp.ho...

I understand your options are limited until AWS adds first-class PHP support but there are still plenty of superior ways you could arrange this. You're running the PHP CLI as opposed to using a persistent process daemon and speaking to it over one of the other SAPIs (e.g. FastCGI). You're also completely defeating the inherent async properties of NodeJS too by launching a synchronous PHP process, and you're completely missing the benefit of "pre-warming" servers. Only the NodeJS aspect gets to pre-warm but a PHP process must launch from cold for every single request.

340ms is not a good response time at all. You need to elevate your expectations.

That's quite insightful. I see you really know what you're talking about and any examples or snippets will be helpful. You are also welcome to collaborate with me on the project for fun if you want (it was a great challenge for me). I'll probably look into it again next weekend to implement your suggestions.

How much do you reckon we can get the response time with these optimizations? Right now the 340ms is nodejs + php-cli + my wrapper script (that inits s3, etc) + the actual content script (another php file) and request for the css framework from a CDN.

You can't launch a persistent process on AWS Lambda.

You most definitely can. Lambda freezes the state of the container and thaws it for the next request (assuming the next request is relatively soon, otherwise it deletes the frozen instance entirely -- This is the entire premise behind keeping lambda functions "warm") including any background processes that might be running.

It's not persistent in that it exists between requests, but for the use case here it's exactly what is needed. He would save significant response time by having php-fpm already running, code parsed, opcodes cached and just issuing a new FCGI request to php-fpm instead of relaunching the PHP CLI each and every time.