How does this compare to OpenResty?
Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support
31–40 of 64 posts
Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support
#32This 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
For self-contained architecture-specific server binaries, there is no practical difference between 240KB, or 2.4MB, or 24.4MB, or even, at a stretch, 244MB. It's not worth mentioning or optimizing for, except as novelty. I wish people would stop golfing with these numbers.
[deleted]
Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support
#33How does this compare to OpenResty?
I suppose this one offers an all-in-one package, while openresty is really just an nginx server with builtin Lua(JIT) support.
Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support
#34"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.
I heared somewhere (Some blogs comment section, I believe) that gzip actually reduces the security of HTTPS; maybe someone can confirm / explain that?
Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support
#35"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.
I heared somewhere (Some blogs comment section, I believe) that gzip actually reduces the security of HTTPS; maybe someone can confirm / explain that?
Compression technologies, including gzip, obviously have the goal of making things smaller by predicting later data based on earlier data. If the later data looks more like the earlier data, the result is smaller than if it was random gibberish. Compression!
If an attacker controls /some/ of this data, and would like to read /other parts/, they can abuse compression to measure whether the parts they don't know are "like" the part they control, because if they are then the compression will make the results shorter than otherwise which they can passively measure.
It's not a problem to move a compressed object over a secure channel on its own, the problem arises if either you try to compress the channel which is moving objects from different origins (e.g. a cookie set by a random advertising web site and your Facebook password) or compress a composite object e.g. maybe your backups mixed with a file you downloaded from a dodgy "pirate" video site.
Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support
#36"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.
Tomcat, one of the most used Java application servers and the default server behind Spring Boot applications defaults to a "compressionMinSize " value of 2048.
The docs do not explain why.
Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support
#37"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.
I did some quick benchmarking and for files under roughly 4096 bytes, not compressing with gzip was faster.
It's not terribly exact, +-1000 bytes would probably not make a big difference, but I think it's a good default.
And of course, some people may have unique use cases where a custom threshold may be better.
Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support
#38Earlier quoted context omitted.
You would need find an application where the binary image size is a problem. In an age where 1TB SSDs are 300 USD this will be ... challenging. You are able to have about a thousand gigabyte sized images on that one SSD and I suspect you will hit CPU and I/O limits well before you have a thousand different binaries running for real. Media storage would go on spinning rust disks anyways separate from the SSD(s).
The consideration isn’t binary size, but hot-loop cache coherency. Big binaries cause code-segment cache-line eviction.
Then that's a typical case of optimizing on the wrong metric.
Find a case where it's actually too slow, ok, but saying "A does X, and X can lead to Y, therefore A does Y" is wrong.
If you say the size of the binary is an issue, then give the issue, not how it could (or not) be an issue.
Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support
#39This 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
Algernon would be a lot smaller if it was not statically compiled and compiled with gccgo instead.
Sadly, the Go package that provides support for QUIC does not compile with gccgo, yet.
Re: Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support
#40Earlier quoted context omitted.
A big part is almost certainly the difference between dynamic and static linking. Can you run ldd on all of these and then report the combined size for each binary+libraries?
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/