fff-fra1: 4 GB RAM

Moexe moexe at freifunk-franken-hassfurt.de
Sa Okt 24 21:47:02 CEST 2015



> Am 24.10.2015 um 20:46 schrieb delphiN <lists at wunschik.net>:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Am 24.10.2015 20:13, schrieb Moexe:
>> Habe testweise auch mal einen squid3 für 2 Hoods aufgesetzt.
> 
> Genau um Tests gehts uns ja auch. Hast du Details?
> Wie hoch war die Catch Rate?

Wenn ich das noch richtig im Kopf hatte, lag die catch rate so bei knapp 10% aller http Anfragen. Fand ich eigentlich schon ziemlich gut. 
> Wieviel GB Cache hast du verwendet?
Hatte 10GB der niemals  voll ausgelastet (1 Woche Testbetrieb für die beiden Haßberge Hoods) war was aber auch sehr zu Lasten des Servers gegangen ist. CPU load und Arbeitsspeicher liefen bei der kleinen VM auf 100%. Erster Grund das Ding wieder auszuschalten.
> 
>> Leider brachte der keinerlei Performancegewinn.
> 
> Das vermute ich auch. Werden das jetzt mal für ein paar Tage testen,
> wieviel % das tatsächlich bringt. Viel kann es eigentlich nicht sein,
> jetzt wo zum Glück das meiste über HTTPS läuft.
Ja, evtl. kann man mit der richtigen config da bessere Ergebnisse erzielen.
> 
>> Außerdem sind manche Seiten wie z.B.: der Netmon, teilweise einfach
>> dann zu "alt" wenn man nur refreshed.
> 
> Das kann ich mir sehr gut vorstellen. Ist aber ein Entwickler-Fehler
> im Netmon. Im HTTP Standart sind Caching Proxies auf jeden Fall
> vorgesehen:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html
Ok, wusste ich nicht.
> 
>> Zudem klappt das interne Routing mit der im Wiki stehenden config
>> nicht. Man kann also keine IP aus dem 10.50.0.0/16  Netz
>> erreichen.
> 
> Das stimmt. Da gibt es auch eine Mänge anderer Probleme.
> Die Config im Wiki sollte so nicht verwendet werden!
Sollte ich dann im Wiki noch mit dazuschreiben.
> 
>> Ich denke auch, dass ein Transparent Proxy einfach nicht auf ein
>> Freifunkgateway gehört.
> 
> Hast du nicht gerade gesagt das du Squid bereits in zwei Hood im
> Einsatz hattest?
Ja, ich wollte testen ob der Proxy das Netz in der Hood entlastet, tut er aber nicht. Der Traffic im Netz is gleich. Allein der Traffic ins www wird nur unmerklich weniger. Zudem will ich das Freifunk-Netz ja selber nutzen. Was bringt es mir dann wenn ich meine eigene owncloud, oder Webcam nicht erreichen kann? 
> Warum der Gesinnungswechsel?
> 
Das Ganze geht Lasten des Gatewayservers der mit fastd und openvpn schon genug zu tun hat. Kann man natürlich durch die entsprechende Hardware ausgleichen und steht meiner Meinung nach aber nicht im Verhältnis zum Nutzen. 

Zudem können da auch viel Daten missbraucht werden. Die Url wird ja auch mit IP gecached. Bin da ja richtig erschrocken, als ich zum testen der config, mal 5 min mitgeloggt habe. 

Ich wollte also solche Daten nicht auf meinem Server gespeichert haben. Man weiß ja nie.

Deswegen hatte ich mich dazu entschieden, den Gatway das machen zu lassen, was er soll, den Traffic durchleiten und fertig. Keine Daten zu speichern.

Zudem hatte ich mir damals nochmal das 
Pico Peering Agreement 
angeschaut, und bin gleich beim ersten Punkt gestolpert:


Der Eigentümer bestätigt, die Daten, die seine freie Netzwerkinfrastruktur passieren, weder störend zu beeinträchtigen, noch zu verändern.
Da habe ich das ganze wieder gelöscht und für Freifunk als nicht vereinbar und auch nicht dienlich angesehen.

Wie gesagt, in wieweit es sinnvoll ist einen transparenten Proxy für die aux zu betreiben, kann ich nicht beurteilen, da es ja in dem Sinn kein Freifunk ist, und das pico peering Agreement hier nicht zum Tragen kommt. Oder sehe ich das falsch?

Grüße Moexe
> delphiN
> 
> - -- 
> freifunk at wunschik.net
> delphiN at jabber.ccc.de
> Mitglied: Freie Netze e.V., CCC, Piratenpartei
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> 
> iQIcBAEBAgAGBQJWK9IgAAoJEGuH2dOBPapC9M8QAMdyyA2qHq7zHW8Z4qTPwJun
> mx7jON82A/lku010gArojBS9J+/0+i/D8x5yY8qWAk7i69LixNLdSFQt7JTG/bBy
> 4AgPDLUFIba2Hc8wFbvIkWQvK+92kN9CHJp9OVVjHejkQdklPjB79E3LduwbYDM0
> tv6LAdiIkqE/4hv0V0Yv/4Ojmq5iWDlIiMmB0Y1wpyXvHXSWx4n97fVjxMOfYSn0
> +6q8u2qx1wclW/kqlkA6Z2WzaLFAZOVs/smPGw1tJ8JpyLhkp+lmHiUvjgmH59GD
> db2UVhfT7fc9n3/MrSdoW0M7B1wKNb8QAmdXj9Iqfxq1b/bz8fkA8d+x9Sw7nzyE
> +ae2Nr49fp7glZ0Jhk0GqEsomV050/JDLYwc3ae2/WDc4goRLEUWZxkfZSBhz31n
> gf0gdZ9NPTmI8F5vx11NIGwAesjSYDFALxhZ5qbkNTevhqUF7okRIo4QjbZcDvBD
> sGNSGeTyRDOW4KTN5JfsGI4CjTVwxJXxLR6gnYVIJ8tQ5cKRWZTLY2OqMRwVsrej
> Xs5/DiH9C2AxkgblitL4sJbdmTXcG4esENFHDeOlH0e7wzRxkcCsK2J6tXoltE1A
> SUQQOprx+6ggCoZlOAQbIoVgJGzy9p0vragk5jyDGV43IJburHAcuVNllo/bOvB/
> A3TfBnkyOtlvyF9R08Kb
> =2Mh+
> -----END PGP SIGNATURE-----
> -- 
> franken-dev mailing list
> franken-dev at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20151024/d6a21885/attachment-0002.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 2565 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20151024/d6a21885/attachment-0002.bin>


Mehr Informationen über die Mailingliste franken-dev