unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: 44567@debbugs.gnu.org
Subject: [bug#44567] [PATCH] publish: Improve HTTP performance when not using --cache.
Date: Fri, 13 Nov 2020 18:19:03 +0100	[thread overview]
Message-ID: <87361dcgzc.fsf@gnu.org> (raw)
In-Reply-To: <20201111035727.11184-1-maxim.cournoyer@gmail.com> (Maxim Cournoyer's message of "Tue, 10 Nov 2020 22:57:27 -0500")

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> This change harmonizes the way we configure the buffer sizes and the socket
> options, so that we don't forget to change it at one place like it happened in
> commit 5e3d169945935b53325e6b738a307ba286751259.  Using a greater socket
> buffer size reportedly improves throughput tenfold.
>
> The solution was found by Ludovic Courtès.
>
> * guix/scripts/publish.scm (%default-buffer-size)
> (%default-socket-options): New variables.
> * guix/scripts/publish.scm (configure-socket): New procedure.
> (compress-nar): Use %default-buffer-size for the buffer size, increased from
> 128 to 208 KiB.
> (nar-response-port): Likewise, increased from 64 to 208 KiB.
> (http-write): Use configure-socket to set socket options.
> (open-server-socket): Likewise.

Apologies for not noticing this before pushing
1cbda46d4aae5ba9bd89a1837f0d81a29653ed7b.  What you propose here is
nicer.

> +(define %default-buffer-size
> +  (* 208 1024))

Why 208?  Did you notice a difference compared to 128KiB?  (I’m fine
either way, just wondering.)

Perhaps add a comment as to what buffer we’re talking about.

> +(define %default-socket-options

Maybe add: ;; List of options passed to 'setsockopt' when transmitting files.

> +  (list (list SO_SNDBUF %default-buffer-size)))

>       (make-gzip-output-port (response-port response)
>                              #:level level
> -                            #:buffer-size (* 64 1024)))
> +                            #:buffer-size %default-buffer-size))

Does the gzip buffer size have to match the TCP buffer size?  I’d say
not necessarily, so perhaps we should have a separate variable for the
gzip buffer size (or keep it as is).

That’s it, thank you!

Ludo’.




  reply	other threads:[~2020-11-13 17:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-11  3:57 [bug#44567] [PATCH] publish: Improve HTTP performance when not using --cache Maxim Cournoyer
2020-11-13 17:19 ` Ludovic Courtès [this message]
2020-11-16  5:12   ` bug#44567: " Maxim Cournoyer
2020-11-16  8:26     ` [bug#44567] " Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87361dcgzc.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=44567@debbugs.gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).