[Wien] Warum ist das FunkFeuer-Wiki so langsam?

Peter Kuhm (spam-protected)
Mi Aug 5 16:16:37 CEST 2020


Hi,

On Wed, 5 Aug 2020 13:36:09 +0200 Christoph Loesch wrote:

> Am 03.08.2020 um 07:28 schrieb Peter Kuhm:

> >> ja, ist wieder sehr langsam. Gefühlt etwas schneller als letztes Mal.
> >> Jetzt läuft das erst seit ca 6,5h und ist vielleicht eh bald fertig
> >> bevor mensch das wirklich braucht. Beim letzten Mal lief es viele
> >> Tage unbrauchbar langsam.
> > Die Antwortzeit vom Wiki war tagsüber schon noch länger beeinträchtigt,
> > nicht nur in den frühen Morgenstunden. Mit letzteren könnte ich leben.
> >
> > Mir wurde auch ausgerichtet, dass ich mit meinen Mails den Adi verärgern
> > würd, der nichts dafür kann, was so nicht meine Absicht ist, aber ich
>
> wieso würdest du damit den Adi verärgern? Hat sich Adi dazu gemeldet?

nein, hat sich auch nicht off-list bei mir gerührt. Beim Subject gehts
ja klar um eine Vereinsangelegenheit. Ein einigermaßen performantes
Wiki ist wichtig für die Innen- und Außenkommunikation. Es freut mich
jedenfalls wenn gelegentlich auch nur ein +1 kommt. Damit wird bestärkt/
erinnert, dass das angesprochene Thema auch andere interessiert. Durch
die verschiedenen Kommunikationskanäle ist das nicht gleich für alle so
ersichtlich.

Folgefragen (s.u.) -wichtig fürs Verständnis- blieben unbeantwortet.

Wenn keine Antwort kommt, so kann das übersehen worden oder der Urlaubs-
zeit geschuldet sein. Ich hab dann halt freundlich nachgehakt aber auch
zunehmend von taktischen Snickers-Reserven gesprochen. Ob das heutzutage
passiv-aggressiv rüberkommt und Verärgerung auslösen kann, weiß ich nicht.


=== SNIP ===
Datum: Fri, 10 Jul 2020 09:19:09 +0200
Von: Peter Kuhm <(spam-protected)>
An: (spam-protected)
Betreff: Re: [Wien] Warum ist das FunkFeuer-Wiki so langsam?


Ahoi,

On Fri, 10 Jul 2020 08:56:37 +0200 Adi Kriegisch wrote:

> > > > > Sobald der Check mal fertig ist, werd ich ein paar Volumes, die sehr I/O
> > > > > intensiv sind, auf anderen Storage verschieben...
> > [...]
> > > Das ist schon a voll zache Gschicht'. Könnte wir uns schon fragen
> > > ob wir das nicht vielleicht mit Hardware bewerfen wollen, damit
> > > das künftig performanter geht.
> > Wie eingangs schon erwähnt, es werden dann ein paar Volumes auf anderen
> > Storage verschoben.
> Volumens sind verschoben.

super, das Wiki flutscht jetzt. Danke!

Magst noch den Hintergrund erklären?
Was verursacht sie vielen I/O-Zugriffe?
Sind die Volumes auf einer Hardware mit schnellerem Interface?
Hat der Check auffällige Inkonsistenzen festgestellt?
Wie wird das am nächsten ersten Sonntag aussehen?

Die Frage zum gegenwärtigen Backup Konzept?


Mit sonnige(n) Grüßen,
Peter
=== SNAP === 


> Aber ist ja nicht so, dass es keine freiwilligen Helfer gibt, die 
> sich gern auch darum kümmern würden.
> Unterstützung sollte eben auch angenommen und zugelassen werden wenn
> Maintainer, warum auch immer, nicht in der Lage dazu sind einen
> Service entsprechend zu warten.

Adi ist Senior Sysadmin und kann sicher performante System bauen und
warten. Wenns kein Feedback gibt wird nachgefragt - was ich hiermit mache.

Wenn Wiki, Forum,.. aus irgendwelchen nachvollziehbaren Gründen auf
einem anderen host laufen sollen, lässt sich das sicher machen.

Ich hoffe das alte "Wir gegen Die" wird mal überwunden und wir können
alle am selben Strang ziehen.

> > glaub einfach nicht, dass man das 2020 längerfristig hinnehmen muss,
> > auch bei sparsamen Einsatz der Vereinsmittel. YMMV.
> +1

Geht nicht darum, alles in einem 64k Demoscene-Beitrag unterzubringen.


> > Die verschobenen Volumes haben das Problem jedenfalls nicht vorständig
> > behoben. Ein solche Antwortzeit ist kein Aushängeschild.
> 
> sehe ich genau so.
> 
> LG Christoph

cu,
Peter




Mehr Informationen über die Mailingliste Wien