Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running PHP fast at the edge with WebAssembly

wasmer.io

Post reply on HN
Print view View original

81–90 of 98 posts

Re: Running PHP fast at the edge with WebAssembly

#81

Post by 1oooqooq »

eknkc wrote: post #59
TekMol wrote: post #16

Let me try to understand this "Edge" thing: - The user sends an HTTP request to somesite.com - Their DNS query for somesite.com gets resolved to some datacenter near them - The HTTP request arrives at the datacenter where the PHP in WebAssembly is executed at half the speed of native PHP - The PHP in Webassembly sends database queries to a central DB server over the internet - The PHP in Webassembly templates the dat…

I guess if you have a use case with higly cacheable data on edge, it might work great. For example, a form builder like typeform could cache form definitions on edge and render them close to users. Submissions would require db communication but the entire experience could be better. Otherwise it is just not worth it. BTW, I don’t even think PHP running slower in wasm would be that important. These things generally de…

> WASM is also pretty fast these days so..

ironically everything is petty fast and everyone waste that speed adding things that allow for a cheaper labour. wasm included. it went from a "have some expertly optimized code in the browser" to "just compile this hide cpp thing and ship as a react component" to then "it allows our servers to run any crap without knowledgeable staff in each language"

we added so many Layers to cheapen labour that now all the labour costs goes into managing the Layers.

Re: Running PHP fast at the edge with WebAssembly

#82

Post by Delmololo »

TekMol wrote: post #16

Let me try to understand this "Edge" thing: - The user sends an HTTP request to somesite.com - Their DNS query for somesite.com gets resolved to some datacenter near them - The HTTP request arrives at the datacenter where the PHP in WebAssembly is executed at half the speed of native PHP - The PHP in Webassembly sends database queries to a central DB server over the internet - The PHP in Webassembly templates the dat…

Big providers have stable and fast and encrypted connection channels between edge and backend.

Client talks to closest system, TLS gets terminated as soon as possible.

Certain things can be cached on edge which normally can't be cached just through basic http (like as soon as you are logged in).

Re: Running PHP fast at the edge with WebAssembly

#83

Post by fhuici »

iruoy wrote: post #44
afavour wrote: post #30

Earlier quoted context omitted.

Ah. Point still stands though, distributed storage is what really unlocks this concept. Wordpress is a pretty bad example though, surely you’d just CDN cache the pages!

opcache doessn't cache user data. it's for caching bytecode in memory as long as the php script/server is running i'd like to see a comparison against a firecracker vm and a docker container

Hi, on kraft.cloud we use FC, along with a custom controller and very specialized VMs (unikernels) to have extremely efficient deployments (eg, millisecond cold starts). For a PHP web server, for instance, we can cold start things in about 30ms (https://docs.kraft.cloud/guides/php/). It's also possible to run wasm workloads/blobs (e.g., https://docs.kraft.cloud/guides/wazero/).

The builds are based on Dockerfiles, but for deployment we transparently convert that to unikernels.

Re: Running PHP fast at the edge with WebAssembly

#84

Post by fhuici »

lxgr wrote: post #63
tambourine_man wrote: post #61

Earlier quoted context omitted.

But we already have containers and VMs are cheap. I find WASM interesting from a technical perspective, but not from a practical one.

“Containers are not a sandboxing mechanism”, I hear reasonably often (although that seems surmountable at least in theory?). VMs are cheap, but not “let’s run thousands of them on ‘the edge’ in case we get a request for any of them!” cheap.

On kraft.cloud we can (done internal stress tests for this) run thousands of specialized VMs (aka unikernels) scaled to zero, meaning that when a request for one of them arrives we can wake it up and respond within the timescales of an RTT. You can take it out for a spin, just use the -0 flag when deploying to do scale to 0 (https://docs.kraft.cloud/guides/features/scaletozero/).

Re: Running PHP fast at the edge with WebAssembly

#85

Post by fhuici »

tambourine_man wrote: post #61
lxgr wrote: post #48

Earlier quoted context omitted.

One thing WASM runtimes usually do really well is sandboxing. Various interpreters might or might not have a good capability/permissioning model (Java's is capable but complex and not supported by many applications, for example); even if they do, there might be exploitable bugs in the interpreter itself.

But we already have containers and VMs are cheap. I find WASM interesting from a technical perspective, but not from a practical one.

100% agree.

In almost all cloud deployment, whether transparently or not, you'll have a hypervisor/VM underneath for hardware-level/strong isolation reasons. Using wasm on top of that stack only for isolation purposes might not be the best use of it. Having said that, if wasm is useful for other reasons (e.g., you need to run wasm blobs on behalf of your users/customers), then my (admittedly biased) view is that you should run these in an extremely specialized VM, that has the ability to run the blob and little else.

If you do this, it is entirely possible to have a VM that can run wasm and still only consume a few MBs and cold start/scale to 0 in milliseconds. On kraft.cloud we do this (eg, https://docs.kraft.cloud/guides/wazero/ , wazero, 20ms cold start).

Re: Running PHP fast at the edge with WebAssembly

#86

Post by fhuici »

aeyes wrote: post #18
tredre3 wrote: post #7

Earlier quoted context omitted.

In this context the edge is a fancy word to say "serverless". It just means that your PHP interpreter will be started on-demand on a node closer to your customer's request. So if your website receives no requests, it costs you nothing. And requests have less latency for the user. That's the theory anyway, in my experience reality is a lot more nuanced because the serverless node still has to reach a database and so o…

This was solved 10 years ago with services like AppEngine in GCP and similar products in major cloud platforms, they all scale to zero.

Yes, though I'd like to point out that "scale to zero" is a loose definition to mean anything that can be transparently scaled to 0 whenever an app/service is idle, and then wake up when traffic to the service arrives once again.

The problem in practice with Cloud Run (and similar products from other providers) is that it can take seconds or minutes for the platform to detect idleness, during which you're still paying, and then seconds to wake up -- during which users/clients have to wait for a response or possibly leave the service/site.

For my taste, real scale to 0 would be: detection and scale to 0 within As a shameless plug, this is what we do at kraft.cloud (based on years or research, LF OSS work, unikernels, a custom controller and overall non-negligible engineering effort).

Re: Running PHP fast at the edge with WebAssembly

#87

Post by fhuici »

jw1224 wrote: post #8
ahofmann wrote: post #5

I'm still trying to understand what this does and what's the use case. Is the "edge" a server? The browser? Why should I compile WordPress or Laravel to wasm?

The “edge” in this case is the browser (from a pure WASM standpoint, though I see these guys also offer a hosted serverless version too). For most general-purpose applications, there’s no point to WASM. But some apps may run specific functions which take a long time (e.g. bulk/batch processing), and being able to execute those tasks securely on the client side provides immediate feedback and better UX. That’s just on…

The edge within this context means running a server close, in terms of Internet latency, to users. For example, if a user if sending a request from Germany, then the response should come from a server running in say Frankfurt, not the US. There are now many providers that allow devels to deploy services at many different locations at once, and to ensure that client requests are routed to the closest available location. An understandable source of confusion is that wasm comes from the browser world, but it's also possible to run it as standalone (no browser) server code.

Also not to be confused with the term edge within the context of IoT/embedded, where the edge is devices running at the very edge of the Internet, e.g., factory floors, trucks, etc.

Re: Running PHP fast at the edge with WebAssembly

#88

Post by fhuici »

mike_d wrote: post #45

Please stop calling it "at the edge." You have seven locations all in highly developed Equinix datacenters. Edge means getting embedded into ISP networks, cell towers, smaller metros, etc.

Actually it means both, in an unfortunate case of term overload. Though I can understand the embedded/IoT world being frustrated by this, as the term existed first within that context.

Re: Running PHP fast at the edge with WebAssembly

#89

Post by phendrenad2 »

lxgr wrote: post #48
maxloh wrote: post #39

Given that we run PHP on the edge, what is the point of running the PHP interpreter on top of a WebAssembly interpreter (Wasmer) instead of just running the PHP interpreter directly? The latter will always be faster.

One thing WASM runtimes usually do really well is sandboxing. Various interpreters might or might not have a good capability/permissioning model (Java's is capable but complex and not supported by many applications, for example); even if they do, there might be exploitable bugs in the interpreter itself.

But compiling PHP to WASM exposes you to the same classes of interpreter (but now compiler) bugs.

Re: Running PHP fast at the edge with WebAssembly

#90

Post by tambourine_man »

kennethallen wrote: post #64
tambourine_man wrote: post #61

Earlier quoted context omitted.

But we already have containers and VMs are cheap. I find WASM interesting from a technical perspective, but not from a practical one.

When Cloudflare Workers launched, they said V8 isolates had some great properties for serverless-style compute: 5 ms cold starts vs 500+ ms for containers 3 MB memory vs 35 MB for a similar container No context switch between different tenants' code No virtualization overhead I'm sure these numbers would be different today, for instance with Firecracker, but there's probably still a memory and/or cold start advantage…

But in this case, it's running PHP, which doesn't have a long-running model, it always cold starts, and it does so really fast natively. I can't see how it could be faster in WASM.
Post reply on HN