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

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

#61

Post by nodesocket » Fri, Apr 05, 2019, 9:29 PM UTC

nnx wrote: post #11

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.

Nginx uses a similar optimization with a configurable threshold defaulted to 1kb.

Correct, the NGINX configuration should be something like:

    gzip on;
    gunzip on;
    gzip_http_version 1.1;
    gzip_proxied any;
    gzip_comp_level 5;
    gzip_disable "msie6";
    gzip_vary on;
    gzip_min_length 2048;

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

#62

Post by xyproto » Sat, Apr 06, 2019, 12:41 PM UTC

mtw wrote: post #56

What is the benefit of using this? In what scenario would this excel? Thanks.

Good question. I'm not sure if it excels in any scenario. There are specialized web servers that excel at caching or at raw performance. There are dedicated backends for popular front-end toolkits like Vue or React. There are dedicated editors that excel at editing and previewing Markdown, or HTML.

I guess the main benefit is that Algernon covers a lot of ground, with a minimum of configuration, while being powerful enough to have a plugin system and support for programming in Lua. There is an auto-refresh feature that uses Server Sent Events, when editing Markdown or web pages. There is also support for the latest in Web technologies, like HTTP/2, QUIC and TLS 1.3. The caching system is decent. And the use of Go ensures that also smaller platforms like NetBSD and systems like Raspberry Pi are covered. There are no external dependencies, so Algernon can run on any system that Go can support.

The main benefit is that is is versatile, fresh, and covers many platforms and use cases.

For a more specific description of a potential benefit, a more specific use case would be needed.

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

#63

Post by xyproto » Sun, Apr 07, 2019, 1:37 PM UTC

yetanotherme wrote: post #27

takeda wrote: post #17

Earlier quoted context omitted.

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

With UPX the entire docker image with Algernon takes only 9MB.

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

#64

Post by koffiezet » Thu, Apr 11, 2019, 3:53 PM UTC

est31 wrote: post #5

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?

I don't have nginx installed (got the number from a web download of the .deb package), but running this for apache: $ echo $((`ldd /usr/sbin/apache2 | cut -d">" -f 2 | sed "s/(.*$//;s/ //" | xargs du -L | cut -f 1 | sed "s/$/+/" | xargs echo` 0)) 3200 So 3.2 MB of shared library dependencies. 1.8 MB just being the libc which is almost guaranteed to be used by a different program already.

> 1.8 MB just being the libc which is almost guaranteed to be used by a different program already

Not if we're talking about containers :)