21–30 of 34 posts
Really wish "serverless" also meant that it can work with AWS Lambda efficiently. As is, each function would try to open a connection, making the overall overhead extremely high and stressing DBs.
> The endpoint is a simple proxy that routes your queries to a rapidly scaled fleet of database resources.
That doesn’t seem to preclude a multiplexing proxy a la PgBouncer.
Last week I created a small framework called lambdaphp[1]. My aim was to host a Wordpress or Laravel site on aws lambda without paying any monthly hosting charges. I got everything running (sessions, fs, request, etc) except of course I still had to use RDS and I think this takes care of it too. So now I can expect to run a full site which is only billed by the amount of resources consumed. Of course my project was j…
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.
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...
Earlier quoted context omitted.
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.…
340ms is not a good response time at all. You need to elevate your expectations.
Really wish "serverless" also meant that it can work with AWS Lambda efficiently. As is, each function would try to open a connection, making the overall overhead extremely high and stressing DBs.
Are you sure? That is, do you have specific knowledge of the implementation? Because: > The endpoint is a simple proxy that routes your queries to a rapidly scaled fleet of database resources. That doesn’t seem to preclude a multiplexing proxy a la PgBouncer.
Earlier quoted context omitted.
Can't you open the connection outside of the function? So as long as the function is hot, it won't reconnect.
That's right. Make connections to databases (and most other things) the first time your Lambda handler runs, and stash them in a static/global variable for re-use on future runs. That allows you to amortize the cost of forming the connection over many executions of your function, which improves latency, reduces cost, and reduces load on the backend.
Earlier quoted context omitted.
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.…
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 completel…
Earlier quoted context omitted.
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 completel…
You can't launch a persistent process on AWS Lambda.
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.
Earlier quoted context omitted.
That's right. Make connections to databases (and most other things) the first time your Lambda handler runs, and stash them in a static/global variable for re-use on future runs. That allows you to amortize the cost of forming the connection over many executions of your function, which improves latency, reduces cost, and reduces load on the backend.
Haven't heard of this approach yet. Do you have a write up I could reference to try it out?
edit: https://medium.com/@tjholowaychuk/aws-lambda-lifecycle-and-i...
Earlier quoted context omitted.
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.…
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 completel…
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.