AG:Technik/Protokolle/Meeting 2013-01-08

Aus Piratenwiki
Wechseln zu: Navigation, Suche
Arbeitsgruppe
Technik

Protokoll der letzten Sitzung im Wiki: http://wiki.piratenpartei.at/wiki/AG:Technik/Protokolle/Meeting_2013-01-01

Dieses Protokoll im Wiki: http://wiki.piratenpartei.at/wiki/AG:Technik/Protokolle/Meeting_2013-01-08

Beginn: 08.01.2013 - 20:00 Uhr

Ende: 08.01.2013 - 23:00 Uhr

Anwesend:

Gäste:

Entschuldigt:

Inhaltsverzeichnis

Agendapunkte

Zusammenfassung der letzten Wochen

  • von: Considerator

In erster Linie Fehlt es somit nur mehr an Inhalten...

  • Admidio Maschine: php Mail endlich ordentlich konfiguriert bisher ging irgendwie noch immer nicht alles über mail01 - jetzt schon (postfix entsprechend konfiguriert)
  • Buchungssystem wird langsam fertig... Derzeit aber noch nicht public da derzeit ohne Benutzerrechteverwaltung - wird jetzt zur Probe getestet
  • Performance Wordpress
    • Considerator hat eine Varnish 2.1 VM am stonekeeper eingerichtet.
    • Wiki läuft jetzt mit Vanish
    • Es gibt jetzt ein erweitertes Varnish-http-purge plugin für Wordpress, das die notwendige Kommunikation übernehmen würde.
      • Feintuning auch bei Wordpress selbst ist noch notwendig, Basisfunktionalität wäre vorhanden (ohne https aware - force https bei wp-admin ist noch nicht möglich, redirect in pound wäre möglich).
        • Jetzt ist auf allen LO-WP Maschinen force https aktiv und es funktioniert (auch mit varnish)...
  • Nachtrag Performance Varnish - Mediawiki
  • siehe auch: http://wiki.piratenpartei.at/wiki/Taskforce:Technik/Protokolle/Meeting_2013-01-01#Performance_Wordpress (vorsicht, diese Überlegungen basieren in erster Linie auf Messungen aus der USA
    • Mediawiki hat seit der 1.17-er Version bereits einen SEHR optimierten loader und selbst ohne Varnish wird alles gecached.
    • Die Ladezeiten sind da in erster Linie von den äußeren Randbedingungen abhängig - DNS-, TCP-, SSL-handshakes, Laufzeit.
    • wiki.piratenpartei.at/wiki/Hauptseite hat zB. laut webpagetest (IE8) aus Frankfurt ideal ~1.636s bzw. 0.803s (repeat view).
      • DNS lookup schwankt ~0.05-0.15 (ob im chache)
      • Varnish reduziert die Reaktionszeit von etwa 0.11 auf etwa 0.07s
      • DEUTLICHE Unterschiede ergeben sich in diesem Fall bei anderem Standort - USA verdoppelt durch die Laufzeiten die Handshakes und die Reaktionszeit auf ~0.2s
      • SEHR teuer von der Ladezeit her, ist SSL. Der erste connect mit Schlüsseltausch kostet ~0.9s die weiteren weiteren kosten ~0.05s extra. Außerdem ist dabei die Kompression ausgeschaltet (openssl komprimiert, nicht der webserver. Dieser Aspekt ist bei pound derzeit in allen Debian Paketen nicht konfigurierbar. Wartet derzeit auf Aufnahme in Sid - ist auch als work-around gegen CRIME. Wäre auch ressourcenschonender...), was die Datenübertragungen verlangsamt.
  • varnish bringt bei einem Hit etwa 0.28s (also ohne varnish wären die Zeiten: ~1.912s / 0.797s
  • aus der USA dauert der Zurgriff etwa 1.1s/0.35s länger.
  • SSL kostet 0.95s / 0.35, SSL aus der USA kostet nur 0.8s / 0.35s
  • Fazit: Varnish bringt da etwa 10%
  • Nachtrag Performance Varnish - Wordpress
    • Wordpress ist sehr cookielastig, viele JS/CSS files, viele Bilder, teilweise unnötig groß.
    • einiges wird per php berechnet / erzeugt DB-lookups.
      • viele connects, teilweise von winizigen Dateien, da fällt dann die Reaktionszeit stärker ins Gewicht
  • out-of-the-box reduziert varnish (bei http!) die Reaktionszeit für die loop von 1.1s auf 0.2s, bei den vielen winzigen Dateien wird varnish im Moment vernutlich durch die Anzahl der Threads begrenzt. bei diesen statischen Dateien ist lighttpd teilweise deutlich schneller
  • Gesamtbild wäre derzeit:
    • 6.75s / 3.80s http/default (momentan auf der startpage glaube ich kein supercache aktiv)
    • 5.15s / 3.15s http/varnish
    • 7.30s / 3.85s https/default
  • Es gibt ein paar Details wo momentan deutlich Zeit verloren geht - in erster Linie der (unnötige) css import für "wiki embed", die PHP-Kompression und ineffiziente Bilder (Low hanging fruits).
    • Das bringt auch in etwa 1 Sekunde.
  • mit einer mittleren Umstellung habe ich noch eine weitere Sekunde herausgeholt, das ist aber nicht ganz stabil - das caching der Seite verhindert dann das auffüllen der caches von minify.
  • mit einem von Grund auf auf Performance aufgebauten Theme (kann optisch sogar fast identisch sein) und vermutlich einer alternative für den Event-Manager, und auf optimierter static file download wären sicher Zeiten von unter 2 Sekunden, vermutlich sogar von ~1 Sekunde möglich.
  • Fazit: varnish bring in diesem Fall etwa 20%, es ist aber kein Wundermittel (in erster Linie kann man die Reaktionszeit bei PHP-content senken, also eigentlich "unsinniges" Tuning machen. Also tuning, das zwar die Übertragung beschleunigt, aber die Reaktionszeit des Servers so verlansamt, dass normalerweise das Ergebnis eher langsamer ist)

Die Zeiten und die daraus resultierenden Werte schwanken. 10% sind zumindest auf der Startseite realistisch.

Der eigentliche Vorteil mit varnish ist, dass man damit Stoßzeiten deutlich besser überstehen kann. Derzeit haben wir normalerweise so wenig Last auf der Homepage, dass für static content lighttpd scheller als varnish ist. Gibt es viel gleichzeitige Zugriffe, würde normalerweise die IO bremsen, mit varnish sind selbst hunderte parallelle Zugriffe kein Problem.

  • Probleme mit dem Caching/Varnish/Supercache
  • siehe auch: http://wiki.piratenpartei.at/wiki/Taskforce:Technik/Protokolle/Meeting_2013-01-01#Caching_Ausnahmen
    • Varnish braucht einen passenden purge, wenn sich die posts ändern oder updates eingespielt werden etc. - das sollte mit meinem plugin gelöst sein.
    • Widgets erzeugen teilweise unabhängig davon anderen output - zB. der event-manager. Das dürfte mit einer passenden TTL - vermutlich eine Stunde handhabbar sein
    • Nutzungsstatistiken werden durch varnish ggf. verändert, da die zähler nicht mehr getriggert werden könnten. Wenn piwik mit dem JS / web-bug auskommt, dürfte das dann relativ problemlos sein.
    • Diverse Plugins cachen selbst, allerdings ist teilweise nicht gesichert, dass diese auch gefüllt werden, wenn die Hauptseite nicht am Server ausgeführt wird.
      • Das könnte auch mit supercache passieren. Das betrifft einen Teil der interessanteren Minify Plugins
  • Ticketflut im Redmine
    • die Kommentare der Homepage erzeugen einen Haufen Tickets.
    • und auch noch jeweils doppelt.
    • Script um via IMAP doppelte Mails zu filtern?
      • das hilft leider überhaupt nicht. Derzeit kommen die Mails in technik@ normalerweise einzeln an, es werden meist aber 2 tickets erzeugt :-(
  • Diverses
    • Das wieder Forum hat jetzt ein neues SSL-Zertifikat - für forum.wien.piratenpartei.at
    • unipiraten verwalten jetzt selbst deren Mailaccounts (juli und weini).
    • Variantenreichtum für Mailaccounts teilweise gewünscht. Zuletzt quasi alle Varianten wie man Niederösterreich, Landtagswahl und 2013 auch abgekürzt als Mailaccount schreiben könnte.

Kalender Wordpress

(vertagt, da die Verantwortlichen nicht anwesend sind)

Mailaccount Formular

  • von Considerator
    • mindestens 10 stelliges Passwort fordern

(vertagt, da die Verantwortlichen nicht anwesend sind)

Redmine helpdesk/mail

  • von Considerator

Teilweise werden Mails nicht eingelesen. Außerdem werden Mails teilweise verdoppelt Das ursprüngliche rakeskipt war da deutlich berechenbarer. Ich frage mich, ob es möglich wäre die Tickets wieder durch das alte Skript zu erzeugen und trotzdem automatisch mit dem Kontacts/Helpdesk plugin die Beantwortung mit email zu ermöglichen (also das Ticket mit dem Ersteller/reply-to zu verknüpfen)? Nachdem welche Probleme mit dem Helpdesk Plugin auftauchen, würde es mich nicht wundern, wenn das auf ein fehlendes locking beim multithreading hinausläuft.

SG Projekt in Redmine

  • von Considerator

In der BSG Sitzung ist das Thema aufgekommen den internen Verteiler auf Redmine umzustellen. Allerdings derzeit scheint niemand Root Projeke erstellen zu können?!

(vertagt, Ticket ist bereits erstellt)

HTTPS / Varnish auf den Wordpress VMs

  • von: Considerator

HTTPS - Plugin: An sich reagiert Wordpress auf https requests (force https admin area/login), mit aktivem https plugin betrifft das auch die links zu den plugins/themes. (Das war die Ursache für das "Loginproblem") Damals habe ich bei der bundes vm einen https connect zwischen pound und vm eingerichtet. Mittlerweile habe ich auf die einfachere Header Variante umgestellt. Damit kann die gesamte Webseite (ohne admin Bereich) per varnish gecached werden. Varnish reagiert auch auf den header und speichert beide Versionen. Varnish HTTP Purge extended - Plugin: Damit wird sowohl ein gezielter purge request bei Änderungen bei den Post gesendet, es ist aber auch möglich für die gesamte Subdomain den Cache zu leeren (Button auf der Plugin Options Seite). Es wäre aber sinnvoll dann den wp-supercache zu deaktivieren und kompression im php zu aktivieren. Die relevanten use-cases sollten alle von meinem varnish vcl abgedeckt sein. Die Hit-rate ist ziemlich gut - fast alles, was nicht userspezifisch ist, wird gecached, Redundanzen vermieden. Wenn die VMs wieder synchrone plugin/theme folders haben macht auch die spetielle optimierung Sinn - diese werden in varnish dann nämlich auf allen VMs auf die Bundesseite gemapped. Derzeit würden Posts/Startpage mit einer TTL von 1 Stunde gespeichert. Eine höhere TTL zumindest bei semi-statischen Seiten würde die Hitrate erhöhen (wir haben ohnehin automatische purges). Momentan eher unnötig, könnte aber wenn der Wahlkampf richtig losgeht noch wichtig werden.

  • update: die Startpage ("/" ist auf 1 Stunde, der Rest auf einen Tag minimum TTL gesetzt)

Aktualisierung LO-Wordpress

  • von Considerator

Wordpress 3.5 auf allen VMs, wieder alle VMs per rsync theme&plugin synchronisieren. Dann Varnish davor.

synchronisation der VMs nach der Sitzung durchgeführt und varnish bei der Bund sowie den LO Wordpress VMs zwischengeschaltet. (Graz, Basis etc. ist davon nicht betroffen) Wordpress/plugin upgrade steht noch an.

Nächste Sitzung

Von „https://wiki.piratenpartei.at/w/index.php?title=AG:Technik/Protokolle/Meeting_2013-01-08&oldid=23761“
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Navigation
Pirat*innenpartei
Mitmachen im Wiki
Werkzeuge
Drucken/exportieren