Caddy and next-server

Meta SC Next
1

So after some dicussion with @sujato we decided to give the Caddy webserver a trial, instead of Nginx. In order to do this I created a new $5 VPS with Linode and it is now running Caddy, and serving next.suttacentral.net

  • It is using automatic HTTPS, it is as simple as Caddy claims it to be.
  • It is using caddy-git and a Github webhook to automatically deploy the website. That is there is no separate deploy step, just git push and the changes will immediately go live on next (the webhook means github sends the server a message informing it a push has happened, so it can immediately pull).
  • I enabled QUIC, you probably wont notice anything, but can see it’s working using the this chrome plugin
  • It is using a development setup meaning very short expiry (2 minutes) on resources, so the performance is not representative of what it would be in production.

As a quick summary of the difference between Nginx and Caddy. Nginx does about 3 things and does them exceptionally well: serve static files, proxying, and caching. It doesn’t do much else. Caddy is a veritable jack-of-all-trades, if Nginx is a knife, then Caddy would be a swiss army knife. The main limitation of Caddy is that some of its most advanced features like QUIC won’t work through a CDN like Cloudflare.

3 Likes
2

Okay, very cool.

I’m getting some bugs; the “tools” dialogue is displaying as an overlay on text pages. This is similar to what happened before, and Ayya found out it was a lack of all required dependencies. Fixed now!

Also, i’m not seeing QUIC enabled on it. Now I can see it!

3

Now, i realize this is going to have probably no relation to the final product, but I remembered that we had thought that QUIC might work better in China, so just for the heck of it I threw the new and old sites at a tester and this is what happened:

image
image1602Ă—1113 160 KB

image
image1608Ă—1115 164 KB

So it’s gone from “my god my god why hast thou forsaken me” to “only a bit worse than London”, which is nice. To be clear, the results from running the tests multiple times vary a lot, but this was more or less typical.

I also ran the test at https://www.webpagetest.org and in Yangzhou, China we got first view at 7.112s.

Also interesting is that repeat visit times are very fast across the board.

4

Before you get too excited about QUIC, I tried running a speed test with QUIC enabled, then repeated it with QUIC disabled.

First number is QUIC

* Average 1st visit: 13.1s vs 12.5s
* Average 2nd visit: 1.1s vs 1.9s 
* Shanghai  1st    : 14.2s vs 12.6
* Shanghai repeat  : 1.3s vs 1.3s

The differences are not statistically significant.

I suggest the main difference you observed is not from QUIC but instead due to bypassing cloudflare. Cloudflare sometimes, maybe usually, gives a nice page load time improvement. But not always.

Where QUIC would probably result in the biggest advantages is on connections with a lot of dropped packages, i.e. crappy mobile connections. It is also quite possible that the repeat visit performance difference is real: because when the browser has never talked to a server it takes two back-and-forths to establish that QUIC can be used (the whole “do you speak QUIC? yeah I speak QUIC. Cool, lets speak QUIC then”), then QUIC will be used on subsequent connections.

2 Likes