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

61–70 of 98 posts

Re: Running PHP fast at the edge with WebAssembly

#61

Post by tambourine_man »

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 we already have containers and VMs are cheap.

I find WASM interesting from a technical perspective, but not from a practical one.

Re: Running PHP fast at the edge with WebAssembly

#63

Post by lxgr »

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.

“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.

Re: Running PHP fast at the edge with WebAssembly

#64

Post by kennethallen »

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.

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 to V8 isolates.

https://blog.cloudflare.com/cloud-computing-without-containe...

Re: Running PHP fast at the edge with WebAssembly

#65

Post by Cyberdog »

maxloh wrote: post #38
syrusakbary wrote: post #4

Earlier quoted context omitted.

Author here. Faster than it has ever been in the Edge via WebAssembly :) But you are completely right pointing out that there's still some room to improve, specially when compared to running PHP natively. Right now there's some price to pay for the isolation and sandboxing, but we are working hard to reduce the gap to zero. Stay tuned for more updates on this front!

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.

From what I can tell it's because some of these "edge" service providers will expect you to give them a WASM binary instead of a PHP script.

The other caveats about "edge" throughout this discussion aside, if I needed to do this, I'd try to write something in Zig or (gag) JS or something else that compiles to WASM directly rather than writing a script for an interpreter that runs under WASM.

Re: Running PHP fast at the edge with WebAssembly

#66

Post by kentonv »

e1g wrote: post #41
kevincox wrote: post #28

Earlier quoted context omitted.

It's complicated but typically yes. The simplest reason is that TCP+TLS handshakes require multiple round trips for a fresh connection. The CDN can maintain a persistent connection to the backend that is shared across users. It is also likely that the CDN to backend connection goes over a better connection than the user to backend connection would.

> The CDN can maintain a persistent connection to the backend that is shared across users We considered using Cloudflare Workers as a reverse proxy, and I did extensive testing of this (very reasonable) assumption. Turns out that when calling back to the origin from the edge, CF Workers established a new connection almost every time, and so had to pay the penalty of the TCP and TLS handshake on every request. That ki…

This didn't sound right to me so I did some investigation and I think I found a bug.

Keep in mind that Cloudflare is a complex stack of proxies. When a worker performs a fetch(), that request has to pass through a few machines on Cloudflare's network before it can actually go to origin. E.g. to implement caching we need to go to the appropriate cache machine, and then to try to reuse connections we need to go to the appropriate egress machine. Point is, the connection to origin isn't literally coming from the machine that called fetch().

So if you call fetch() twice in a row, to the same hostname, does it reuse a connection? If everything were on a single machine, you'd expect so, yes! But in this complex proxy stack, stuff has to happen correctly for those two requests to end up back on the same machine at the other end in order to use the same connection.

Well, it looks like heuristics involved here aren't currently handling Workers requests the way they should. They are designed more around regular CDN requests (Workers shares the same egress path that regular non-Workers CDN requests use). In the standard CDN use case where you get a request from a user, possibly rewrite it in a Worker, then forward it to origin, you should be seeing connection reuse.

But, it looks like if you have a Worker that performs multiple fetch() requests to origin (e.g. not forwarding the user's requests, but making some API requests or something)... we're not hashing things correctly so that those fetches land on the same egress machine. So... you won't get connection reuse, unless of course you have enough traffic to light up all the egress machines.

I'm face-palming a bit here, and wondering why there hasn't been more noise about this. We'll fix it. Talk about low-hanging fruit...

(I'm the tech lead for Cloudflare Workers.)

(On a side note, enabling Argo Smart Routing will greatly increase the rate of connection reuse in general, even for traffic distributed around the world, as it causes requests to be routed within Cloudflare's network to the location closest to your origin. Also, even if the origin connections aren't reused, the RTT from Cloudflare to origin becomes much shorter, so connection setup becomes much less expensive. However, this is a paid feature.)

Re: Running PHP fast at the edge with WebAssembly

#67

Post by burnte »

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.

Why are we running this stuff at the edge anyway? Wasn't the point of the web to permit light/thin clients? What problem is this really solving? I feel a lot of these new methods exist simply out of "holy crap look what we can do" factors. I have a hard time thinking that running a PHP interpreter in WASM on a smartphone is a smart idea.

"What if our code ran in tens of thousands of different environments that we have no control over, rather than a single server environment we control!"

Re: Running PHP fast at the edge with WebAssembly

#68

Post by moomoo11 »

Joel_Mckay wrote: post #36
moomoo11 wrote: post #33

Can someone ELI5 what is does "edge" computing means? The way I understand it is that is moving some operations closer to the client to avoid bandwidth costs and improve performance. I thought of the Tesla car computer as edge computing, as it does a lot of processing within the car that would otherwise add latency and reliance on a internet connection. But for web browsers? Going to some websites? What sort of apps…

Hi, traditionally for our purposes it solved a few problems. 1. latency 2. intermittent access 3. distributed "meaningful" data preparation/filters One may consider routers with squid proxies, VoIP trunks, and p2p cache are essentially similar "edge" technologies. There are additional use-cases, but we don't want to educate the lamers stealing resumes off jobs sites... having no clue what they are talking about. Have…

Oh ok I see lol

Re: Running PHP fast at the edge with WebAssembly

#69

Post by e1g »

kentonv wrote: post #66
e1g wrote: post #41

Earlier quoted context omitted.

> The CDN can maintain a persistent connection to the backend that is shared across users We considered using Cloudflare Workers as a reverse proxy, and I did extensive testing of this (very reasonable) assumption. Turns out that when calling back to the origin from the edge, CF Workers established a new connection almost every time, and so had to pay the penalty of the TCP and TLS handshake on every request. That ki…

This didn't sound right to me so I did some investigation and I think I found a bug. Keep in mind that Cloudflare is a complex stack of proxies. When a worker performs a fetch(), that request has to pass through a few machines on Cloudflare's network before it can actually go to origin. E.g. to implement caching we need to go to the appropriate cache machine, and then to try to reuse connections we need to go to the…

> So if you call fetch() twice in a row, to the same hostname, does it reuse a connection?

In my testing, the second fetch() call from a worker to the same origin ran over the same TCP connection 50% of the time and was much faster.

We want to use Workers as a reverse proxy - to pick up all HTTP requests globally and then route them to our backend. So our use-case is mostly one fetch() call (to the origin) per one incoming call. The issue is that incoming requests arrive to a ~random worker in the user's POP, and it looks like each Worker isolate has to re-establish its own TCP/TLS connection to our backend, which takes a long time (~90% of the time).

What I want is Hyperdrive for HTTPS connections. I tried connecting to backend via CF Tunnel, but that didn't make any difference. Our backend is accessible via AWS Global Accelerator, so Argo won't help much. The only thing that made a difference was pinning the Worker close to our backend - connections to the backend becamse fast(er) because the TLS roundtrip was faster, but that's not a great solution.

Re: Running PHP fast at the edge with WebAssembly

#70

Post by zackify »

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…

That’s why you gotta use liteFS on fly.io or cloudflare d1. And of course, don’t use php
Post reply on HN