Hood-Bildung - Gemeindegrenzen

Adrian Schmutzler mail at adrianschmutzler.de
Fr Sep 21 11:48:17 CEST 2018


Hallo Christian,

ich habe gestern noch über den Cache nachgedacht.

Zunächst ein Detail:
Es ist problematisch, Indizes auf Float-Werte zu legen. D.h. im Cache müssen die Koordinaten immer als string (z.B. CHAR(16) oder so was) abgelegt werden, sonst wird die Performance grottig. Ich glaube, das ist im Skript ohnehin so, da du ja direkt die GET-Werte nimmst. (Oder man rechnet auf int um oder so Firlefanz, ist bei der kleinen Tabelle aber nicht nötig)

Dann ein Problem:
Das große Problem beim KeyXchange ist, dass alle 1000-2000 Anfragen gleichzeitig (in der selben Sekunde) ankommen. Die wollen dann alle in dieser selben Sekunde am Cache rumschreiben und rumlesen. Das reine Lesen wäre jetzt überhaupt kein Problem, aber sobald du was schreiben willst, werden bestimmte Bereiche der Tabelle gelockt. Will jetzt ein zweiter Router im selben gelockten Bereich schreiben (oder lesen), macht es bumm, und es gibt ein Deadlock (d.h. der Code macht nen Error und bricht ab). Das wars dann für den Router, er kriegt keine Antwort.
Sind wir in der Phase des Cache-Aufbaus, wird das am Anfang sehr oft hintereinander der Fall sein, und ein Teil der Router kriegt dann z.B. eine halbe Stunde keine korrekten Daten o.ä.
Ich habe vergleichbare Probleme beim Monitoring durchaus gelegentlich, obwohl hier die Gleichzeitigkeit von Aufrufen sehr selten ist.
InnoDB ist hier zwar recht gut, aber gerade in Tabellen mit mehr als einer Index/Unique-Spalte (i.e. lat/lng) wird das richtig schlimm.

Ich gehe davon aus, dass du in deinem Test die Anfragen alle hintereinander gemacht hast?

Müsste man mal was mit Multi-Threading nehmen und 256 Anfragen oder so gleichzeitig reinbrüllen und dann messen, wieviel 500er zurückkommen.
Ich habe leider keine Zeit, sonst würde ich schnell was mit C# bauen.

Mir fällt nichts ein, wie man das generelle Problem wirklich beheben kann. Man könnte es aber auf verschiedene Arten lindern:
- Man baut am Anfang des Skriptes ein kleines random ein (0-10 sec). Das ist zwar Mist, aber wird die Rate der locks senken (ich werde demnächst sowas für die Firmware rumschicken)
- Man gibt die Antwort an den Router schon raus und schreibt DANACH in den Cache (dann geht es nur kaputt, wenn das deadlock beim Lesen entsteht, aber nicht, wenn es beim Schreiben entsteht. Ich glaube aber, die entstehen immer beim Lesen...).
- Man setzt das Schreiben im Cache in einen try/catch Block (wie zuvor nützt das nur was, wenn das Schreiben kaputt geht, beim Lesen trotzdem kaputt)
- Man schreibt die Strings für lat und lng hintereinander in einen String und macht daraus einen Single-Index (höhere Such/Lese-Zeit, aber weniger Locks, da kein Clustered-Index (glaube ich zumindest))
- Man lässt den Cache weg (dann haben wir sicher keine Locks, dafür dauert es halt u.U. ewig bis ne Antwort kommt, dafür kommt sich sicher (irgendwann...))

Anmerkung zum Schluss:

$sql = "INSERT INTO cache(lat,lon,hoodid) VALUES ('$lat','$lon','$hoodid')";

Das geht kaputt, wenn zweimal gleichzeitig die gleichen Koordinaten kommen (beide finden sie nicht im Cache (gleichzeitig) und dann wollen beide sie später deswegen reinschreiben). Was man hier macht:

$sql = "INSERT INTO cache(lat,lon,hoodid)
VALUES ('$lat','$lon','$hoodid')
ON DUPLICATE KEY UPDATE
	hoodid=VALUES(hoodid)
";

(Unter der Annahme, dass lat und lon zusammen den PRIMARY KEY bilden.)

Abgesehen davon ist das ein Königreich für SQL-Injection.

So, fertig mit mosern.

Grüße

Adrian


> -----Original Message-----
> From: franken [mailto:franken-bounces at freifunk.net] On Behalf Of Christian
> Dresel
> Sent: Freitag, 21. September 2018 10:07
> To: michael at fritscher.net; Freifunk Franken <franken at freifunk.net>
> Subject: Re: Hood-Bildung - Gemeindegrenzen
> 
> hi
> 
> On 19.09.2018 12:14, michael at fritscher.net wrote:
> > Moin,
> >
> > kurz: klingt lecker :-) Danke fürs Ausprobieren!
> >
> > 2 Anmerkungen:
> >
> > 1. Die Umrüstung von mysql auf pqsql dürfte eigentlich recht einfach
> > machbar sein, gerade beim v2 Keyxchange. Ist mir aber egal, wenn die php
> > Variante auch gut funktioniert (scheint sie ja bisher).
> > 2. Was sagt die Performance? Du könntest ja mal Schaittach 100x auf die
> > Karte klatschen, immer bissle verschoben, und gucken was passiert, wenn
> > alle durchgeschaut werden. Wenn das max. 2-3 Sekunden dauert könnte man
> > das durch einen Cache ablindern. Wir haben ja nur Größenordnung 5k
> > Router, also 5k unterschiedliche Koords, da könnte man die
> > Koord->Hoodzuordnung speichern. Der Cache würde dann halt bei
> > Hoodänderungen geleert werden.
> >
> > Grundsätzlich wäre ich klar für weiter ausprobieren :-)
> 
> dein Wunsch war mir Befehl. Ich hab den keyxchange mal bei mir
> aufgesetzt und sowohl Cache nach diesem Beispiel:
> https://wiki.freifunk-
> franken.de/w/Hood_als_Polygon#Idee_mit_Cache_.28Christian.29
>  sowie die komplette Polygon Hood nach diesem Beispiel
> https://wiki.freifunk-
> franken.de/w/Hood_als_Polygon#Idee_mit_PHP_.28Christian.29
> integriert.
> Dazu ist aktuell der Debugmodus an, so das man auch "sieht" was aktuell
> gerade passiert. Ausprobieren könnt ihr die Abfragen hier:
> 
> http://fff-
> jupiter.fff.community/keyxchange/VPNkeyXchange/index.php?lat=49.618443&
> long=11.327268
> (ohr könnt gerne mal verschiedene Koordinaten dagegen werfen)
> 
> Als PolyHood hab ich mal eine Fakehood Schnaittach angelegt. Ich glaube
> das ist der Bereich um Simmelsdorf der da abgebildet wird (NICHT
> Schnaittach selbst, aber ist ja jetzt eh nur zum probieren)
> 
> Meinen Umbau hab ich mal bei mir ins git geworfen:
> 
> https://github.com/ChristianDresel/VPNkeyXchange (Branch keyxchangev2)
> die letzten 2 Patches (ich merk gerade wo ich mit der Mail fertig bin,
> das die Datenbankstruktur noch fehlt, wer sie unbedingt sehen will
> einfach mal rufen, dann lad ich das irgendwo mit hoch)
> 
> Eine Funktion fehlt noch, aktuell wird nur gegen eine PolyHood und nicht
> gegen alle die es in der DB gibt geprüft (index.php Zeile 264 WHERE
> id='1' müsste man noch austauschen und durch alle IDs die es in der db
> gibt prüfen), das muss noch eingebaut werden. Ansonsten ist es voll
> funktionsfähig.
> 
> Aber so ganz grundsätzlich kann man sich jetzt mal überlegen ob man das
> haben will oder nicht und man hat jetzt auch bisschen Code vor Augen.
> 
> mfg
> 
> Christian
> 
> >
> > Viele Grüße und Danke,
> > Michael Fritscher
> >
> >
> >
> > Am 2018-09-19 11:52, schrieb Christian Dresel:
> >> hi
> >>
> >> um gegen ein System zu sein, sollte man ein System erstmal verstehen.
> >> Bisher war ich dagegen, weil ich dachte es ist zu aufwendig. Aber hey
> >> ich spiel doch gerne mit Technik und so hab ich mal bisschen
> >> herumprobiert.
> >> Mein Ergebniss möchte ich nun mal der Community vorstellen und würde
> >> mich über bisschen Feedback (sowohl technisch als auch nicht technisch)
> >> freuen.
> >>
> >> Ich hab Markus seine Anleitung erstmal soweit abgearbeitet das ich eine
> >> GeoJson File von Schnaittach (und Simmelsdorf und noch irgendein
> >> Nachbarort den Markus genannt hat) lokal hatte, das sieht dann so aus:
> >>
> >> http://fff-jupiter.fff.community/schnaittach.GeoJson
> >>
> >> Hier drinnen ist bereits für jeden Ort ein MultiPolygon (keine Ahnung ob
> >> das der richtige Begriff ist, aber so wird es hier genannt) enthalten.
> >>
> >> Nun ist der Punkt von Markus "Ist-in-Abfrage" allerdings nicht ganz
> >> leicht umzusetzen, der keyxchange hat keine PostgreSQL und das
> >> nachzurüsten uff... Will ich mir eigentlich ersparen. Also hab ich mal
> >> geguckt wie ich das in PHP (damit ist der keyxchange geschrieben)
> >> einfacher lösen kann. Ich bin dabei auf diese Funktion gestolpert:
> >>
> >> http://assemblysys.com/php-point-in-polygon-algorithm/
> >>
> >> Man muss jetzt aus der GeoJson natürlich ein Array erstellen, dies hab
> >> ich erstmal händisch gemacht (das in ne Schönform zu bringen sollte
> >> technisch kein Problem sein) mit dem Bereich Simmelsdorf, sieht dann
> >> so aus:
> >>
> >> http://fff-jupiter.fff.community/poly/array.txt
> >>
> >> Danach hab ich noch 3 Koordinaten reingeklopft gegen die ich testen will
> >> (später würde der Router hier seine Koordinaten hinschicken und der
> >> keyxchange schaut in welchen MultiPolygon das liegt):
> >> 11.339509 49.559324
> >> 11 49
> >> 11.327267 49.618443
> >>
> >> Im moment sich lat/lon noch verdreht, da die MultiPolygon so aufgebaut
> >> ist, hab ich erstmal damit gearbeitet. Das Ergebnis sieht dann so aus:
> >>
> >> http://fff-jupiter.fff.community/poly/index.php
> >> (Sourcecode kann hier angeguckt werden:
> >> http://fff-jupiter.fff.community/poly/index.txt )
> >>
> >> Man sieht, die Funktion arbeitet auch mit Koordinanten korrekt, die
> >> ersten 2 Koordinaten liegen eindeutig nicht im Bereich Simmelsdorf, die
> >> 3. aber schon.
> >>
> >> So wie könnte man dies nun technisch in den keyxchange klopfen:
> >>
> >> Schritt 1) Der Knoten schickt seine Koordinaten an den keyxchange.
> >> Schritt 2) wir prüfen die Koordinaten gegen alle (ich nenn dieses
> >> Hoodsysten jetzt mal frech so) GeoJson-Hood. Passen die Koordinaten des
> >> Knoten in eine dieser vorhandenen GeoJson-Hoods, wird diese Hood an den
> >> Knoten zurückgegeben und er konfiguriert sich auf diese Hood falls sie
> >> in keine GeoJson-Hood passen, machen wir mir Schritt 3 weiter ansonsten
> >> endet hier der Ablauf bereits
> >> Schritt 3) wir prüfen wie jetzt auch schon, zu welcher voronoi Hood der
> >> Knoten gehört und geben ihn diese Hood zurück.
> >>
> >> Bisher arbeitet der Keyxchange nur mit Schritt 1 und 3, man würde also
> >> einen Schritt 2 "dazwischen" schieben.
> >>
> >> Vorteile:
> >> - Wer GeoJson verwenden will, kann dies tun. Wer es nicht tun will
> >> bleibt einfach bei den alten voronoi System, es ist die freie
> >> Entscheidung jedermann (und das ist mir persönlich sehr wichtig)
> >> - Das GeoJson System liegt "über" den voronoi System. Somit werden Hoods
> >> die aktuell nach voronoi arbeiten absolut nicht beeinflusst sofern "da
> >> drinnen" niemand eine Geo-Json Hood anlegt. Die Systeme können also
> >> wunderbar pararell agieren
> >>
> >> Nachteil:
> >> - Das Zeug muss man erstmal umsetzen
> >> - Der Wartungsaufwand vom keychange steigt etwas an, man muss auf noch
> >> mehr Sachen acht geben
> >>
> >> So Meinungen? Was meint ihr? Umsetzbar? Sollen wir es probieren? Hab ich
> >> Dinge übersehen?
> >>
> >> mfg
> >>
> >> Christian
> >>
> >> On 06.09.2018 09:46, fff at mm.franken.de wrote:
> >>> Moin Michael,
> >>>
> >>>>> Markus, wir können uns da gerne mal (virtuell oder physikalisch)
> >>>>> zamhocken und da was zusammenbrauen ;-)
> >>>
> >>> Habe mal etwas Doku zusammengetragen:
> >>> https://wiki.freifunk-franken.de/w/Hood_nach_Gemeinden
> >>>
> >>> Vielleicht hilft das Dir und anderen Hood-Profis ja ein bisschen?
> >>>
> >>> Rückfragen gern per Mail oder telefonisch.
> >>>
> >>> Mit herzlichem Gruss,
> >>> Markus
> >>>




Mehr Informationen über die Mailingliste franken