Live data from Hacker News

Running PHP fast at the edge with WebAssembly

wasmer.io

21–30 of 98 posts

Re: Running PHP fast at the edge with WebAssembly

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

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 stale data is ok and you can ship data snapshots to the edge so that they can be served without going back to the central DB. But in many cases some basic cache policies with a CDN can be nearly as effective.

Re: Running PHP fast at the edge with WebAssembly

#22
post #18
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.

In GCP land I'd assume Cloud Run is a closer service.

But yes, for full blown applications udually talking to a cache and a DB there are way more efficient and performant solutions already.

Re: Running PHP fast at the edge with WebAssembly

#23
post #20
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…

The post mentions a cache. I think the key here would be not going to the central DB and instead going to a distributed cache. Not an unreasonable concept when I assume the vast majority will be read operations.

That's OPcache they mentioned, a specific language-level cache native to PHP.

https://www.php.net/manual/en/intro.opcache.php

Re: Running PHP fast at the edge with WebAssembly

#25
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 a valid concern, and with a classical centralized DB the Edge solution will not be faster in many cases, especially considering how many DB requests some ORMs like Drupal or Wordpress need for each page load...

Some other providers have tried to solve the problem with replicated databases that are used for local reads.

I can't go into details yet, but Wasmer will offer a solution for this problem quite soon as well, which hopefully will be much more seamless than existing strategies.

(note: I work at Wasmer)

Re: Running PHP fast at the edge with WebAssembly

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

Thank you for explaining. As a Web dev, who's using PHP since version 4, I'm still very confused why someone would consider running a CMS like WordPress on the client side, or at the "edge". I guess the good thing here is that someone spends (a lot of) energy in giving PHP new ways to get used by developers.

This is what is referred to by "edge": https://en.wikipedia.org/wiki/Edge_computing

Re: Running PHP fast at the edge with WebAssembly

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

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?

Re: Running PHP fast at the edge with WebAssembly

#28
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?

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.

Re: Running PHP fast at the edge with WebAssembly

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

Isnt this true of everything that runs on the edge?

Unless you host the database in the same network as your edge provider, appliation database is where the bottleneck is.

Re: Running PHP fast at the edge with WebAssembly

#30
post #23
post #20

Earlier quoted context omitted.

The post mentions a cache. I think the key here would be not going to the central DB and instead going to a distributed cache. Not an unreasonable concept when I assume the vast majority will be read operations.

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!

Post reply on HN