Re: [dev] [quark] Current performance and ideas

From: FRIGN <dev_AT_frign.de>
Date: Thu, 14 Aug 2014 10:57:50 +0200

On Thu, 14 Aug 2014 09:35:07 +0100
Dimitris Papastamos <dp_AT_spl9.org> wrote:

Hey Dimitris,

thanks for the patches you sent in earlier!

> Obviously these numbers do not mean anything unless compared to
> some other http server implementation.
>
> From some quick testing that me and Hiltjo did yesterday, we found
> that nginx is twice as fast. That's ok, quark has no optimizations in
> place and can easily serve a few thousands of clients with static
> content.
>
> Quark uses fork() internally to handle the clients. I think that's a
> bless in disguise. Any other technique (select, poll, epoll, etc.) will
> require some small finite state machine to keep track of the connections,
> recycle the appropriate file descriptors etc. More specific
> interfaces like sendfile(), epoll() etc. are also going to cause problems
> with portability.

We gotta relect on that one.
Compared to fork(), poll()/epoll() are superior and should provide
better throughput.
Regarding sendfile, we need to mind the different definitions on different
systems.

ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
int sendfile(int fd, int s, off_t offset, size_t nbytes,
                 struct sf_hdtr *hdtr, off_t *sbytes, int flags);

And this is just Linux and OpenBSD.

> I will be looking at a poll() based implementation soonish to see how
> it performs versus the complexity. I will post a patch here if I have
> something worthwhile.

I'll stay tuned!

Cheers

FRIGN

-- 
FRIGN <dev_AT_frign.de>
Received on Thu Aug 14 2014 - 10:57:50 CEST

This archive was generated by hypermail 2.3.0 : Thu Aug 14 2014 - 11:00:15 CEST