Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support

github.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support

#41

Post by jand »

tyingq wrote: post #8

"Files that are sent to the client are compressed with gzip, unless they are under 4096 bytes." That's interesting. Is that a common optimization? I hadn't heard of any other web server doing that.

Not a direct answer, but also interesting to consider:

As everything will end up in a packet when sent through the network stack, you might want to choose your minimum input size in such way, that you generate gzip-compressed output big enough. Why big enought? Nagle's algorithm [1]

So yet another reason to think about 'what to gzip'.

[1] https://en.wikipedia.org/wiki/Nagle%27s_algorithm

Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support

#42

Post by chvid »

est31 wrote: post #2

This is quite impressive, but this claim is a bit wrong: > All in one small self-contained executable. Size of algernon executable: 24.4 MiB Size of nginx-full executable: 1.1 MiB Size of apache2 executable: 648K

I don't think it is fair that you are being downvoted.

Size does matter and not just in sense that it is using resources. The largest part of the 24 MB probably never gets executed but it adds unnecessary complexity that may hide bugs and security flaws.

Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support

#43

Post by xyproto »

marcus_holmes wrote: post #25

I wonder why they didn't include Let's Encrypt integration - it's completely painless using the acme library, and that would prevent the whole "HTTP or HTTPS?" discussion around HTTP/2

It's in progress. Algernon is an open source project where I am the main contributor, and I develop Algernon in my spare time. Pull requests are welcome.

Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support

#44

Post by tialaramex »

jand wrote: post #41
tyingq wrote: post #8

"Files that are sent to the client are compressed with gzip, unless they are under 4096 bytes." That's interesting. Is that a common optimization? I hadn't heard of any other web server doing that.

Not a direct answer, but also interesting to consider: As everything will end up in a packet when sent through the network stack, you might want to choose your minimum input size in such way, that you generate gzip-compressed output big enough. Why big enought? Nagle's algorithm [1] So yet another reason to think about 'what to gzip'. [1] https://en.wikipedia.org/wiki/Nagle%27s_algorithm

Applications that always know exactly what they want to send disable this algorithm, as that article explains, by setting TCP_NODELAY or its moral equvialents in their framework. A web server will almost invariably set TCP_NODELAY.

More sophisticated algorithms can either decide exactly which packets to send, or use TCP_CORK to shove part of a packet into a buffer before they add the rest of the stuff, e.g. preparing HTTP headers and then adding the static document that goes after them.

Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support

#45

Post by marcus_holmes »

baldomo wrote: post #40
marcus_holmes wrote: post #24

Earlier quoted context omitted.

As someone else commented, the huge size of Go executables is down to a design decision to include a map of functions for panic reporting. There was a whole discussion on this recently on HN. I don't know why the grandparent was downvoted. Go binaries are not small and the claim that this is a "small" single executable is untrue. Hopefully the Go team will give us a flag to decide for ourselves whether to optimise fo…

You can actually pass LDFLAGS to any go tool (e.g. go build[1]). The flags are specified in the linker documentation[2] [1] https://golang.org/cmd/go/#hdr-Compile_packages_and_dependen... [2] https://golang.org/cmd/link/

which is useful, except as far as I'm aware it doesn't cover this case.

The original is at: https://science.raphael.poss.name/go-executable-size-visuali...

Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support

#46

Post by xyproto »

est31 wrote: post #2

This is quite impressive, but this claim is a bit wrong: > All in one small self-contained executable. Size of algernon executable: 24.4 MiB Size of nginx-full executable: 1.1 MiB Size of apache2 executable: 648K

The docker image is 9MB. https://hub.docker.com/r/xyproto/algernon/tags

Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support

#47

Post by marcus_holmes »

xyproto wrote: post #43
marcus_holmes wrote: post #25

I wonder why they didn't include Let's Encrypt integration - it's completely painless using the acme library, and that would prevent the whole "HTTP or HTTPS?" discussion around HTTP/2

It's in progress. Algernon is an open source project where I am the main contributor, and I develop Algernon in my spare time. Pull requests are welcome.

I'd love to help, but my coding time is already taken building a product.

I pretty much followed the instructions here: https://godoc.org/golang.org/x/crypto/acme/autocert

edit, better here: https://blog.kowalczyk.info/article/Jl3G/https-for-free-in-g...

I didn't believe it could be that simple, but it worked first time and has proven really robust.

Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support

#48

Post by erdii »

marcus_holmes wrote: post #47
xyproto wrote: post #43

Earlier quoted context omitted.

It's in progress. Algernon is an open source project where I am the main contributor, and I develop Algernon in my spare time. Pull requests are welcome.

I'd love to help, but my coding time is already taken building a product. I pretty much followed the instructions here: https://godoc.org/golang.org/x/crypto/acme/autocert edit, better here: https://blog.kowalczyk.info/article/Jl3G/https-for-free-in-g... I didn't believe it could be that simple, but it worked first time and has proven really robust.

It is even easier: https://github.com/mholt/certmagic

Edit: Taken from certmagic docs

Instead of:

// plaintext HTTP, gross

http.ListenAndServe(":80", mux)

Use CertMagic:

// encrypted HTTPS with HTTP->HTTPS redirects - yay!

certmagic.HTTPS([]string{"example.com"}, mux)

Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support

#49

Post by codebeaker »

tyingq wrote: post #8

"Files that are sent to the client are compressed with gzip, unless they are under 4096 bytes." That's interesting. Is that a common optimization? I hadn't heard of any other web server doing that.

Also, according to the spec HTTP servers may not always honour the value in the `Accept-Encoding` header[0].

> Even if both the client and the server supports the same compression algorithms, the server may choose not to compress the body of a response, if the identity value is also acceptable.

I've actually run into this twice in my career and it has been a surprise to those around me in both cases. Both times in the context of small payloads where the server is applying some heuristic about whether to encode or not. (e.g status page stops sending gzipped output when the server is becoming "unhealthy")

[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support

#50

Post by xg15 »

sagichmal wrote: post #16
takeda wrote: post #15

Earlier quoted context omitted.

You have it backwards, apache or nginx size is not for the novelty. Go is just a pig and its size grows every new release, and the size isn't really for being statically linked or debugging symbols, because it's huge even when those options are disabled. Right now a "hello world" application in Go has comparable size to an OS with full GUI.

Who cares? Literally, what problem does it cause, or what does it make worse? It is totally immaterial.

Even if we don't know which particular problem it might cause right now, being wasteful when you can avoid it is never a good idea.

Image size is currently not the most important metric, but - guessing how your average node.js package already looks today - demanding people ignore it completely will probably set you on the road of multi TB images that also contain the developer's favorite desktop environment in the medium future.

Post reply on HN