Live data from Hacker News

Running PHP fast at the edge with WebAssembly

wasmer.io

51–60 of 98 posts

Re: Running PHP fast at the edge with WebAssembly

#51
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…

You're assuming that network latencies follow the triangle inequality, i.e., that A->C is smaller than A->B + B->C. However, that breaks down because of money. It's possible that the user's ISP is a cheapskate without good peering agreements such that while A->B is fast, they haven't setup the necessary agreements to make A->C fast.

I've personally seen this with a game recently and my own ISP. I can ping their West Coast servers in 20-40ms while pinging their Chicago servers takes 200ms+.

This is actually one huge flaw with the current way IP is done. Because your ISP is closely tied with the last-mile of routing, you have very little control over optimizing those backend layers of routing.

This doesn't explain why you wouldn't just run a thin proxy at the edge and instead want to run a full PHP app. For that, my guess is this makes sense when you don't want to run a full server all the time or if you want it to be rapidly scalable.

Re: Running PHP fast at the edge with WebAssembly

#52
https://news.ycombinator.com/item?id=38829557#38834787

>> Ask HN: What are your predictions for 2024?

> Server-side WASM takes off with the re-implementation of PHP, Ruby/Rails, Python, and others, and a WASM based virtual server (shell, filesystem, web server, etc..) Cost more but has better security for both the host and user.

Guess I was wrong about it costing more?

> … we can run PHP safely without the overhead of OS or hardware virtualization.

But it only runs at half the speed of PHP, so you need more resources.

Re: Running PHP fast at the edge with WebAssembly

#53
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…

You're assuming that network latencies follow the triangle inequality, i.e., that A->C is smaller than A->B + B->C. However, that breaks down because of money. It's possible that the user's ISP is a cheapskate without good peering agreements such that while A->B is fast, they haven't setup the necessary agreements to make A->C fast. I've personally seen this with a game recently and my own ISP. I can ping their West…

Okay....but that's you providing a backbone for the user. Don't you just use a CDN at that point? (One that allows non-cached requests as well.)

Re: Running PHP fast at the edge with WebAssembly

#54
post #11
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…

PHP nowadays already has a JIT compiler and its own bytecode, no need for WebAssembly.

This seems like a misunderstanding, WebAssembly has nothing to do with PHP’s internal performance mechanisms. WASM is a compilation target, this means you can take code which needs to be compiled (like PHP’s core binary), and compile it to be run in a browser.

PHP in WASM means developers can run actual, real, native PHP code in the user’s browser, without the user needing to have PHP installed locally, or nginx, etc…

Re: Running PHP fast at the edge with WebAssembly

#55
post #54
post #11

Earlier quoted context omitted.

PHP nowadays already has a JIT compiler and its own bytecode, no need for WebAssembly.

This seems like a misunderstanding, WebAssembly has nothing to do with PHP’s internal performance mechanisms. WASM is a compilation target, this means you can take code which needs to be compiled (like PHP’s core binary), and compile it to be run in a browser. PHP in WASM means developers can run actual, real, native PHP code in the user’s browser , without the user needing to have PHP installed locally, or nginx, et…

Because I always wanted to run PHP in the browser.

Re: Running PHP fast at the edge with WebAssembly

#56
post #54
post #11

Earlier quoted context omitted.

PHP nowadays already has a JIT compiler and its own bytecode, no need for WebAssembly.

This seems like a misunderstanding, WebAssembly has nothing to do with PHP’s internal performance mechanisms. WASM is a compilation target, this means you can take code which needs to be compiled (like PHP’s core binary), and compile it to be run in a browser. PHP in WASM means developers can run actual, real, native PHP code in the user’s browser , without the user needing to have PHP installed locally, or nginx, et…

You could do that, but the post here is in fact about running PHP on a server on top of a Wasm runtime.

“At the edge” basically means “close to the user”, with the details left as an exercise to whoever is selling you their “edge.” In this case, it’s a Wasm runtime company.

Re: Running PHP fast at the edge with WebAssembly

#57
post #2

Whereby fast is "About half the speed of native PHP"

Nb PHP is already really fast. Some major things built on it are slow, mostly due to things like poor data access patterns or architecture, but its culture since the beginning has basically been “get out of PHP and into C as fast as possible” and it shows (this is basically the trick to any scripting language “being fast”, PHP just embraced it hard from the very beginning). If you’re on PHP and need more speed in the…

> PHP just embraced it hard from the very beginning

Which is also the reason why a lot of the PHP standard library functions are so inconsistent. They're straight wrappers around the C libraries.

Upside is, unless you have to do shit with pointer magic or play around the edges of signed/unsigned numbers, it's fairly easy to port C example code for any of the myriad things PHP has bindings to to PHP.

Re: Running PHP fast at the edge with WebAssembly

#59
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 depend on IO performance rather than runtime if you are not doing a lot of calculations on the edge. WASM is also pretty fast these days so..

Re: Running PHP fast at the edge with WebAssembly

#60
post #41

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…

Were you using a Cloudflare tunnel for your origin?
Post reply on HN