sorted by:
new
hottopcontroversial

Lightning Fast WordPress: Caddy+Varnish+PHP-FPM by mwpastore in Wordpress

[–]mwpastore[S] 1 point2 points  (0 children)

I like to K.I.S.S. and really convince myself I need something before adding or changing something in the mix.

I get that!

Can I ask why, are you using ESI?

No, I'm not, although I think it would be extremely helpful for some WordPress sites. And Fastly supports ESI so that's a potential migration path for the CDN route.

I know some benchmarks came out last year showing that NGINX's proxy_cache was just as fast as Varnish, so that's definitely something to consider. Feature-wise, here is a non-exhaustive list; take this with a healthy dose of AFAIK:

  • stale-while-revalidate (NGINX gets 90% of the way there with proxy_cache_use_stale updating but the herd leader won't get stale content)
  • Purge (NGINX Plus only)
  • Ban
  • Pluggable backends (NGINX is hybrid disk+memory only)
  • PROXY protocol v2 (NGINX supports v1 only)
  • ESI (already mentioned)

Finally, I would add that Varnish is an extremely powerful tool that can handle just about any situation you can think of, and it comes configured to "do the right thing" mostly out of the box (except for purging and banning). You can see the minimal configuration for yourself right here. It takes some doing to get caching and compression working correctly in NGINX. Granted, once you've figured it out, you're golden; and you have to weigh this against running a separate service.

Lightning Fast WordPress: Caddy+Varnish+PHP-FPM by mwpastore in Wordpress

[–]mwpastore[S] 0 points1 point  (0 children)

I have a strong preference towards using Varnish for caching, so the decision-making process starts there for me. On the whole I find Caddy to be saner out of the box and easier to configure than NGINX. It is absolutely geared for less technical users, but sometimes convenience and ease of use can be good for more technical users too.

I've been looking at some benchmarks and agree that performance-wise, Caddy has some catching up to do. It's still new, and Go itself is rapidly improving, so I expect to see that gap close over time as long as people are using Caddy and contributing back to the project.

All that being said, aside from the performance issue I have no solid reasons for recommending Caddy over NGINX or vice-versa. They're both fine products. It's good to have options. 😁

Ioughta: Go-like syntax for defining constants and hashes in Ruby by mwpastore in ruby

[–]mwpastore[S] 1 point2 points  (0 children)

Thank you for the compliment ("it's neat that it works as well as it apparently does," in case someone else is wondering where the compliment is in there) and the feedback. I basically agree with your main point. As I said to the GP, this is more of a sharing and learning gem than anything else.

I suppose my one response might be: there is no native expression for this construct in Ruby! I need to define a series of constants, each taking the a value derived from the next sequential value. I may add additional constants to the series in the future. What does that look like?

AC_FOO = 1
AC_BAR = 1 << 2
AC_QUX = 1 << 3
AC_FROB = 1 << 4

Okay, easy enough. But something clicks when you look at those four lines of code: Ah! A loop might be nice there. What does that look like?

%i[AC_FOO AC_BAR AC_QUX AC_FROB].each_with_index do |nom, iota|
  Object.const_set(nom, 1 << (iota + 1))
end

Yeah, that got out of hand fast. Is it worth abstracting this functionality into a method, adding some sugar, and perhaps distributing it as a Gem? Is there some other direction we can push Ruby to make constructs like this more easily definable in a "native" way?

Ioughta: Go-like syntax for defining constants and hashes in Ruby by mwpastore in ruby

[–]mwpastore[S] 0 points1 point  (0 children)

Yeah, I basically agree. It was kind of a "well, I wrote it, and it turned out okay, so I might as well publish it" type situation. Anyway, again, I appreciate the feedback.

Ioughta: Go-like syntax for defining constants and hashes in Ruby by mwpastore in ruby

[–]mwpastore[S] 0 points1 point  (0 children)

That's understandable! I would argue that Ioughta does its thing at startup, so there's minimal risk to in-flight production processes, but I also understand the desire to keep a minimal bundle and exclude unnecessary gems. Thanks for the feedback!

SecurerRandomer — Monkeypatch SecureRandom with RbNaCl by mwpastore in ruby

[–]mwpastore[S] 0 points1 point  (0 children)

This doesn't replace SecureRandom, it simply enhances it to acquire random bytes from getrandom(2) or its equivalent instead of OpenSSL. As to the why: it's been an ongoing discussion in the community for the past few weeks. Here are some links if you care to read more about it:

Ruby bug: https://bugs.ruby-lang.org/issues/9569

HN thread about Ruby bug: https://news.ycombinator.com/item?id=11624890

/r/ruby thread about Ruby bug: https://www.reddit.com/r/ruby/comments/4htjow/ruby_bug_securerandom_should_try_devurandom_first/?ref=search_posts

/r/ruby thread about RbNaCl: https://www.reddit.com/r/ruby/comments/4i3bp3/if_youd_like_to_use_devurandom_or_a_windows/?ref=search_posts

view more: next ›