Live data from Hacker News

Running PHP fast at the edge with WebAssembly

wasmer.io

41–50 of 98 posts

Re: Running PHP fast at the edge with WebAssembly

#41
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 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 killed any performance gains, and was a deal breaker for us. It’s rather difficult to predict or monitor network/routing behavior when running on the edge.

Re: Running PHP fast at the edge with WebAssembly

#42
post #2

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

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!

Hey you should really check out fly.io if you want to run stuff on the edge. They have it pretty much figured out.

FrankenPHP is also really good and probably a much smarter play than trying to get your code running under WebAssembly.

Re: Running PHP fast at the edge with WebAssembly

#43
post #13
post #8

Earlier quoted context omitted.

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…

I don't think edge in this case mean browser. I think edge in this case is more similar to a CDN node.

Yes, the browser is where you land when you fall off the edge :)

Re: Running PHP fast at the edge with WebAssembly

#44
post #30
post #23

Earlier quoted context omitted.

That's OPcache they mentioned, a specific language-level cache native to PHP. https://www.php.net/manual/en/intro.opcache.php

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

Re: Running PHP fast at the edge with WebAssembly

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

Re: Running PHP fast at the edge with WebAssembly

#50
post #27

Earlier quoted context omitted.

Due to connection setup roundtrips, TCP slow start mechanics and quality of network connections it is usually better to terminate the client's TCP connection close to them. But I agree that moving the frontend rendering near the client doesn't really make sense for almost all cases. So the best general purpose setup would probably look like user → CDN → central PHP+DB. Of course there are always exceptions. Often sta…

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.

Post reply on HN