Re: [dev] [quark] Performance issues

From: Laslo Hunhold <dev_AT_frign.de>
Date: Wed, 25 Sep 2019 08:20:52 +0200

On Tue, 24 Sep 2019 11:17:09 -0700
Anselm Garbe <garbeam_AT_gmail.com> wrote:

Dear Anselm,

> The issue is, there are enough http servers, but most of them are
> designed as daemons. As you say, quark could become a nice alternative
> for drop-in purporses. For this it is currently too feature rich
> however. I would suggest to strip it down as follows:

see my remarks below.
 
> - Keep it GET/HEAD based only

I agree of course. :)

> - Always run as current user, if root is used chroot() to current
> directory.

chroot() should never be optional. unveil() might bring the same
effect, but the unveil()-wrapper in quark doesn't do anything on Linux.

> - Always serve current directory as root (no need to supply directory
> option)

I think that would overstretch it.

> - If no explicit port is specified start from 8080 and take next
> available port

I understand this point, given port 80 cannot be bound when not root.
But this is a permission thing and that's what doas and sudo are for.
Especially doas allows you to fine-grain the permissions of specific
applications.

> - Don't support vhosts, if you need that use different server, if you
> need to run multiple instances, use different ports instead

I don't understand how different ports would solve that problem unless
you maybe have a relay that is connected to different quark instances
on an internal network. Publicly, if you have a server serving e.g. 3
virtual hosts, all accesses have to happen on one port.

> - Don't support unix sockets

Agreed, they increase the complexity, but they make quark much more
flexible. For instance, this makes it very easy to attach something like
stunnel to it for TLS.

> - Don't bother with TLS stuff, a drop-in server should not be required
> to use TLS

quark itself doesn't do any TLS, but it's capable of "dealing" with
something like stunnel by giving proper redirects and so forth.

> - Only log to stderr/stdout

That's what it does. :)

> - Eventually add content range support (which might become handy for
> drop-in use cases)

quark supports partial content. This is mandatory if you serve videos
or audio files.

> That's it. I'm sure this can be done within 200 lines. And this should
> be the aim for quark after all. It shouldn't be supposed to be used as
> a general purpose server, as said initially, there are enough already
> to choose from. But there are almost non that offer the feature set
> described.

The most substantial part of quark is not necessarily the host handling
or something like directory-choice (the latter is done in like 4 lines
during the ARG-loop). The HTTP-header parsing alone takes 200 lines and
handles special cases like this crappy IPv6-bracket-notation which is
too easy to miss. Another substantial part is actually the
content-range handling, because it has some intricate details. I get
your point of course, and in a world with only OpenBSD (sadly it isn't)
I would strip out vhosts immediately.

The main problem I see is that there is no "nice" httpd on Linux. We
might move forward and try to port OpenBSD's httpd to Linux and get it
packaged. However, up to this point, quark can act as a lightweight
server even for static purposes on Linux.

With best regards

Laslo
Received on Wed Sep 25 2019 - 08:20:52 CEST