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

71–80 of 98 posts

Re: Running PHP fast at the edge with WebAssembly

#71

Post by e1g »

bluk wrote: post #60
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…

Were you using a Cloudflare tunnel for your origin?

Yes, tried tunnels too. There is significant variability among individual requests, but when benchmarking at scale I found no meaningful difference in p50 and p90 between “Worker -> CF Tunnel -> EC2 -> backend app” and “Worker -> AWS Global Accelerator -> EC2 -> backend app”

Re: Running PHP fast at the edge with WebAssembly

#72

Post by kentonv »

e1g wrote: post #69
kentonv wrote: post #66

Earlier quoted context omitted.

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 in…

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

Again, origin connections are not owned by isolates -- there are proxies involved before we get to the origin connection. Requests from unrelated isolates can share a connection, if the are routed to the same egress point. Problem is that they apparently aren't being routed to the same point in your case. That could be for a number of reasons.

It sounds like the bug I found may not be the issue in your case (in fact it sounds like you explicitly aren't experiencing the bug, which is surprising, maybe I am misreading the code and there actually is no bug!).

But there are other challenges the heuristics are trying to solve for, so it's not quite as simple as "all requests to the same origin hostname should go through the same egress node"... like, many of our customers get way too much traffic for just one egress node (even per-colo), so we have to be smarter than that.

I pinged someone on the relevant team and it sounds like this is something they are actively improving.

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

Argo Smart Routing should have the same effect... it causes Cloudflare to make connections from a colo close to your backend, which means the TLS roundtrip is faster.

Re: Running PHP fast at the edge with WebAssembly

#73

Post by worewood »

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'm gonna counter the other comments that try to justify this somehow, and say:

I agree with you, and it's not faster. With the risk of sounding old (get off my lawn): I assure you the megabytes of unneeded Javascript they're downloading to the client are ten times slower to execute than the milliseconds they may be saving on the wire.

Re: Running PHP fast at the edge with WebAssembly

#74

Post by e1g »

kentonv wrote: post #72
e1g wrote: post #69

Earlier quoted context omitted.

> 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 in…

> 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). Again, origin connections are not owned by isolates -- there are proxies involved before we get to the origin connection. Requests from unrelated isolates can share a connection, if the are r…

Thank you for looking into it in such detail based on an unrelated thread!

Cloudflare seems to consistently make all types of network improvements behind the scenes, so I’ll continue to monitor for this “connection reuse” feature. It might just show up announced.

Re: Running PHP fast at the edge with WebAssembly

#75

Post by rovr138 »

burnte wrote: post #67
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 hav…

Patience apparently

Re: Running PHP fast at the edge with WebAssembly

#76

Post by shanemhansen »

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'm working on something in a similar space. It's not as mysterious as people make it sound:

You do caching so you don't always have to go back to the DB is the main thing. The other interesting capability is light scripting at the edge. Think "this page is cached but I'm going to add in a custom username".

There's some more exotic stuff around sharded database locality. But I'll skip over that because distributed mutable state is hard and its not my specialty.

Connection warming and shorter tls negotiation round trip times are also a thing but probably less important compared to the database thing you are mentioning.

But mostly this architecture makes sense if you can do some caching or if you're doing more data/log collection stuff.

For prior work see ESI (edge side includes). Assembling stuff at the edge does have some benefits but it has been hard to create a good interface for that.

Re: Running PHP fast at the edge with WebAssembly

#77

Post by squigz »

burnte wrote: post #67
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 hav…

> I feel a lot of these new methods exist simply out of "holy crap look what we can do" factors

Welcome to web dev!

Re: Running PHP fast at the edge with WebAssembly

#78

Post by 1oooqooq »

kevincox wrote: post #28
TekMol wrote: post #27

Earlier quoted context omitted.

What I usually do is that I use two hostnames. host1 for http requests which can be cached. That host is behind a CDN. host2 for HTTP requests which can't be cached. That host points directly to my server. Are you saying it would result in a better user experience when I only use host1 which is behind the CDN and add no-cache headers to the request that can't be cached?

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 "it's complicated" part assumes client side requests i guess.

none of this comment applies to back end + db in the same server or colo.

Re: Running PHP fast at the edge with WebAssembly

#79

Post by 1oooqooq »

mschuster91 wrote: post #50
TekMol wrote: post #27

Earlier quoted context omitted.

What I usually do is that I use two hostnames. host1 for http requests which can be cached. That host is behind a CDN. host2 for HTTP requests which can't be cached. That host points directly to my server. Are you saying it would result in a better user experience when I only use host1 which is behind the CDN and add no-cache headers to the request that can't be cached?

> Are you saying it would result in a better user experience when I only use host1 which is behind the CDN and add no-cache headers to the request that can't be cached? Yes, because that way you can leverage the CDN to defend against DDoS issues, and you can firewall the origin server itself so only the CDN is allowed to communicate with it, but no one else.

if your market is not usa or Asia, you actually get DDoSed by using cloudflare et all more often (>1) than not (=0)

Re: Running PHP fast at the edge with WebAssembly

#80

Post by 1oooqooq »

worewood wrote: post #73
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'm gonna counter the other comments that try to justify this somehow, and say: I agree with you, and it's not faster. With the risk of sounding old (get off my lawn): I assure you the megabytes of unneeded Javascript they're downloading to the client are ten times slower to execute than the milliseconds they may be saving on the wire.

yes you are correct. the top comments disagreeing are either full of wrong basic concepts or are very dense in detail while hand waving the important parts and from CDN-for-hire employers.
Post reply on HN