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

21–30 of 64 posts

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

#21

Post by takeda »

Propolice wrote: post #14
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

Algernon does a bit more than plain Nginx or Apache. 24.4 MiB also includes bloat. See: https://github.com/golang/go/issues/27266 https://github.com/golang/go/issues/2559 Hopefully we can get smaller binaries by Go 1.13.

My Apache installation with modules takes 4.3MB, and I'm quite sure Apache with modules can do more than Algernon.

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

#22

Post by Go0the0gophers »

takeda wrote: post #17
sagichmal wrote: post #16

Earlier quoted context omitted.

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

- increases amount of time to fetch and run container (it actually is quite noticeable when you have app that scales out and you updating it) - it increases amount of storage to store multiple versions of containers (when you have an internal app and do frequent releases it adds quickly) - it increases amount of data transferred on every deployment - increases amount of memory used (the whole point of containers, was…

Lol, I let you use java spring boot technology. It is really bloat (ram, cpu, disk, infamous slowly startup and jit optimization, complex tuning eg. thread pool and so on). Good luck.

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

#23

Post by takeda »

chx wrote: post #18
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.

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).

We observed noticeable difference in deployment time and auto scaling based on container size.

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

#24

Post by marcus_holmes »

lawl wrote: post #4
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

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 for executable size or initialisation time. I know I'm fed up of uploading 50Mb files over dodgy wifi+vpn connections to update my server.

(edit fix repetition of design)

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

#26

Post by interfixus »

mholt wrote: post #3
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

If that's the main criticism you have of the project, I'd say that's pretty good. In fact, the readme of this project is really thorough!

Very civilized comment from mr. Caddy himself. Heartening, not least considering the kind of vendettas some projects - Caddy among them - have to put up with from competing developers.

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

#27

Post by yetanotherme »

takeda wrote: post #17
sagichmal wrote: post #16

Earlier quoted context omitted.

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

- increases amount of time to fetch and run container (it actually is quite noticeable when you have app that scales out and you updating it) - it increases amount of storage to store multiple versions of containers (when you have an internal app and do frequent releases it adds quickly) - it increases amount of data transferred on every deployment - increases amount of memory used (the whole point of containers, was…

True. Luckily, most Go binaries can be upx'd ( https://upx.github.io/ ) for a fraction of their original size. Just put it into your Dockerfile as a part of the build process.

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

#28

Post by throwaway5d097 »

marcus_holmes wrote: post #24
lawl wrote: post #4

Earlier 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…

That's one thing that might motivate me to set up CI/CD on a server.

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

#29

Post by TickleSteve »

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.

You have to ask yourself what is that space used for??

They're all compiled languages doing (roughly) the same operations. There is an order of magnitude difference in the number of instructions in one compared to the other.

Apache is more likely to be entirely cached whereas the others aren't.

Size matters for performance.... if you're not CPU bound, fine, but to say its immaterial is naive.

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

#30

Post by derefr »

chx wrote: post #18
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.

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.
Post reply on HN