Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Caddy webserver goes south - Page 5
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Caddy webserver goes south

1235»

Comments

  • rm_ said: did you test Lighttpd performance?

    Haven't in years as went full in with Nginx - without any regrets :)

    Remember old benchmarks for any webserver would usually be non-HTTPS based HTTP/1.1 testing. These days you also need to test for HTTP/2 and HTTP/1.1 based HTTPS as well - h2load tester can test both HTTP/2 and HTTP/1.1 (with --h1 flag) https://nghttp2.org/documentation/h2load-howto.html. Apachebench, wrk, siege all do not support HTTP/2 based HTTPS load testing.

  • For @WSS Caddy GCC 7.1.1 vs Caddy Clang 4.0.1 https://community.centminmod.com/posts/54741/

    Thanked by 1WSS
  • Those are some interesting metrics. I guess that the GNU folk have had more time to optimize/rebuild than CLang, but the fact that a sneeze changes on average 10% in this product still bothers me greatly.

  • ricardoricardo Member
    edited September 2017

    eva2000 said: days you also need to test for

    Indeed, for the modern day work case. I knew nginx's strong point was dealing with and processing connections quickly, and I'd assume that such a large difference in performance in that area is going to have a large bearing on the result any benchmark with more bells and whistles on the servers.

  • @WSS said:
    Those are some interesting metrics. I guess that the GNU folk have had more time to optimize/rebuild than CLang, but the fact that a sneeze changes on average 10% in this product still bothers me greatly.

    Shouldn't bother you, it's known fact that different compilers can effect the resulting built binary's performance. Centmin Mod PHP-FPM is source built like Nginx and supports various compilers and compiler optimisations specifically for Intel processors if detected and can result in up to 2-7% better performance than distro provided PHP binaries for simple benchmarks but also depends on which cpu you're using for the server. Full benchmarks for PHP-FPM 7.2 vs 7.1 vs 7.0 vs 5.6 comparing Centmin Mod PHP-FPM binaries versus Remi YUM repo provided ones at https://community.centminmod.com/threads/php-7-2-0-rc1-released.12746/#post-53951. I've been tracking PHP 7.2 performance since early alphas, betas and now RCs. Reminds me PHP 7.2.0 RC2 is out now http://php.net/archive/2017.php#id2017-09-14-1 so off to retest ^_^

    @ricardo said:

    eva2000 said: days you also need to test for

    Indeed, for the modern day work case. I knew nginx's strong point was dealing with and processing connections quickly, and I'd assume that such a large difference in performance in that area is going to have a large bearing on the result any benchmark with more bells and whistles on the servers.

    Yeah indeed.. though I'm benchmarking Caddy every few new releases, in hopes to see progressive improvements considering Caddy is only at 0.10.9 release !

  • @eva2000 said:

    @WSS said:
    Those are some interesting metrics. I guess that the GNU folk have had more time to optimize/rebuild than CLang, but the fact that a sneeze changes on average 10% in this product still bothers me greatly.

    Shouldn't bother you, it's known fact that different compilers can effect the resulting built binary's performance. Centmin Mod PHP-FPM is source built like Nginx and supports various compilers and compiler optimisations specifically for Intel processors if detected and can result in up to 2-7% better performance than distro provided PHP binaries for simple benchmarks but also depends on which cpu you're using for the server. Full benchmarks for PHP-FPM 7.2 vs 7.1 vs 7.0 vs 5.6 comparing Centmin Mod PHP-FPM binaries versus Remi YUM repo provided ones at https://community.centminmod.com/threads/php-7-2-0-rc1-released.12746/#post-53951. I've been tracking PHP 7.2 performance since early alphas, betas and now RCs. Reminds me PHP 7.2.0 RC2 is out now http://php.net/archive/2017.php#id2017-09-14-1 so off to retest ^_^

    Yes, compiler optimizations can account for a good load- but I was referencing that virtually ANY modification to Caddy can make it worse, such as the fact that it starts failing harder with that header still astounds me. The Go Webserver is obviously not ready for production. I doubt that Google really expects it to be used as one, but then again, there are so many things running lua that go will eventually become mainstream, I'm sure.

    PHP is a different pig. It has a ton of support libraries that it calls as routines directly- so, yeah, I can see SSL/cURL being faster if it has builds for that specific CPU since the optimized code can certainly work better in, say, a CPU that supports AES. PHP is still a semi-interpreter wrapped around a ton of C libraries, and that will never change. This is a webserver built into Go with several hooks. I don't think they're directly relatable- but I see what you're getting at.

  • Yeah only time will tell how Caddy progresses. IIRC, Cloudflare uses or tests Caddy too - so wonder if Cloudflare contribute performance patches to Caddy as they have done for Nginx ? Cloudflare uses Nginx in production so makes sense to squeeze out more performance in Nginx.

  • Matt would probably incorporate them into his non-OSS fork and make them sign an NDA to not disclose that they've made updates/speed/etc fixes in order to incorporate them and add X-Not-A-Header: for them.

  • @WSS said:
    Matt would probably incorporate them into his non-OSS fork and make them sign an NDA to not disclose that they've made updates/speed/etc fixes in order to incorporate them and add X-Not-A-Header: for them.

    Not sure that would be done if Cloudflare used source built Caddy binaries and modifications would be covered under the Caddy source Apache 2.0 license ?

  • That was an attempt at very thick sarcasm.

  • Much like Caddy, though, it failed.

    Thanked by 1sarah
  • oh heh ^_^

  • rm_rm_ IPv6 Advocate, Veteran

    eva2000 said: Haven't in years as went full in with Nginx - without any regrets :)

    Remember old benchmarks for any webserver would usually be non-HTTPS based HTTP/1.1 testing. These days you also need to test for HTTP/2 and HTTP/1.1 based HTTPS as well - h2load tester can test both HTTP/2 and HTTP/1.1 (with --h1 flag) https://nghttp2.org/documentation/h2load-howto.html. Apachebench, wrk, siege all do not support HTTP/2 based HTTPS load testing.

    It's way simpler, Lighttpd doesn't support HTTP/2 at all :) And afaik there are no plans to, unless in 1.5 or 2.0 versions, which kind of "didn't take off" and 1.4 remains the flagship version.

    I chose it years ago instead of nginx due to a more straightforward config system, checked a few benchmarks now, it seems a bit slower or about the same as nginx, though all of those did not test HTTPS.

  • rm_ said: It's way simpler, Lighttpd doesn't support HTTP/2 at all :)

    oh then not touching it .. HTTP/2 HTTPS all the way :D

  • @ricardo said:

    flatland_spider said: The alternatives (IIS, Nginx) are really awful

    I think that's the first time I've heard anyone say that.

    >

    @classy said:

    @ricardo said:

    flatland_spider said: The alternatives (IIS, Nginx) are really awful

    I think that's the first time I've heard anyone say that.

    The guy probably never got further than trying to understand nginx config syntax then...

    >

    Re-read the post. It's specifically about config syntax.

    I don't have anything against Nginx. I just don't have a reason to consider it since Apache added websockets.

  • Heads up for folks thinking of pairing Varnish Cache with Caddy, there are Varnish Cache HTTP/2 HTTPS bugs that affect performance https://community.centminmod.com/posts/54821/

Sign In or Register to comment.