Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Stefan Bethke <stb@lassitu.de>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: galene@lists.galene.org
Subject: [Galene] Re: Additional stats
Date: Thu, 29 Oct 2026 19:44:58 +0100	[thread overview]
Message-ID: <121CCD01-E105-4A60-8BAA-1FDC7865F5C6@lassitu.de> (raw)
In-Reply-To: <87qzhkmpa4.wl-jch@irif.fr>

Hi there,

here is my proposal: https://github.com/jech/galene/pull/349

I will be running this code and testing it with Prometheus and Grafana for the next weeks, and eventually at our event on Dec 27th to 30th, so I will be able to report any practical findings from running it.

Let me know what you think.

Thanks,
Stefan

> On 20. Oct 2026, at 16:15, Juliusz Chroboczek <jch@irif.fr> wrote:
> 
> Hi Stefan,
> 
>> I would be interested in making that endpoint an optional feature in Galéne, and I would additionally be interested in collecting ICE information.
>> 
>> Is there interest in such features, and would it be OK for me to use GenAI (Claude) for the implementation?
> 
> Extra statistics would be useful.  However two caveats:
> 
> 1. Respect user privacy.  For example, the current endpoint does not
>   expose IP addresses or user names.  This is important: people are using
>   galene.org for intimate couple chat (I know because the group names are
>   exposed), and there is at least one priest using Galene for online
>   confession (he's using his own instance, thankfully).
> 
> 2. Don't harm performance, at least when the admin is not monitoring.
>   Galene is very carefully constructed to scale across many cores.  For
>   example, we avoid locking whenever possible, and we try to avoid atomic
>   variables that are shared between more than a few threads.
> 
>   Note in particular that the Go Prometheus library uses global atomics,
>   which is a bad idea, since it causes cacheline bouncing.  (The right
>   solution would be to have per-thread or per-CPU counters, together with
>   periodic reconciliation.)
> 
> I guess what I'm saying is that I'd love you to experiment, but please
> don't be discouraged if I don't accept your first attempt.
> 
> -- Juliusz

-- 
Stefan Bethke <stb@lassitu.de>   Fon +49 175 3288861


  parent reply	other threads:[~2026-10-29 18:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20 11:19 [Galene] Additional stats Stefan Bethke
2026-10-20 14:15 ` [Galene] " Juliusz Chroboczek
2026-10-20 14:53   ` Sebastien Binet
2026-10-20 16:47     ` [Galene] GenAI in Galene [was:Additional stats] Juliusz Chroboczek
2026-10-29 18:44   ` Stefan Bethke [this message]
2026-10-30 11:15     ` [Galene] Re: Additional stats Juliusz Chroboczek
2026-10-30 11:55       ` Stefan Bethke
2026-10-30 12:46         ` Juliusz Chroboczek
2026-10-30 13:19           ` Stefan Bethke
2026-10-30 13:54             ` Juliusz Chroboczek

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://lists.galene.org/postorius/lists/galene.lists.galene.org/

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

  git send-email \
    --in-reply-to=121CCD01-E105-4A60-8BAA-1FDC7865F5C6@lassitu.de \
    --to=stb@lassitu.de \
    --cc=galene@lists.galene.org \
    --cc=jch@irif.fr \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox