• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Neues zum Thema Proxy/Cache...

Gute Idee die alte Krake mal wieder vorzuholen :)

Für MacOS einfach:
- Squid 2.7 squid : Optimising Web Delivery runterladen und mit xcode übersetzen
- Für etwas Komfort SquidMan SquidMan laden und beim installieren NICHT die mitgelieferte Version nutzen, sondern bei 2.7 bleiben (Ich benutze noch SquidMan 2.0)
- In Preferences Port und Cachegröße setzen
- In Template die entsprechenden Anpassungen von oben machen

und läuft hervorragend :)

Damit er auch die üblichen Orte sauber zwischenspeichert, vorher noch den Phoenix eigenen Cache leeren.

Alles in allem. Klasse Idee. Deutlich mehr Performance ohne viel Aufwand.
 
*Grmp*

Nach gefühlten 37 Runden mit der squid.conf-Datei hab ich den Cache-Rechner neu aufgesetzt - mit einer anderen Linux-Distribution.

Fazit: Scheinbar ist SuSE 11.3 etwas zu verbaut oder hat mit dem Squid 2.7 irgendwo ein Problem - oder meine Minibüchse ist mit der SuSE-Kompilation überfordert. Mit Ubuntu 10.10 war es auch nicht problemlos, aber doch möglich, das ganze zum Laufen zu bringen.
 
@Yistin
Ich hab Ubuntu 10.04. Der Cache arbeitet irgendwie aber der Phoenix ist nicht über den Web Proxy eingestellt, denn dann geht gar nichts mehr. Dennoch habe ich Logs in dem Lindenserver aufgeführt werden. Die Performance ist dennoch besser als wenn ich den squid anhalte.

Was hast Du jetzt noch anders gemacht mit Ubuntu 10.10?
 
Es gibt zwei Einstellungen.
Einmal die Einstellung im Viewer selbst, wo du den Proxy und den Port einstellst. Da hat Linden allerdings ziemlich unsauber programmiert: Nach dieser Einstellung laufen die Programmgrafiken (Sidebar, Bildhintergrund beim Start usw) über den Proxycache. Die Texturen im Viewer werden aber über eine Programmbibliothek ("libcurl") geladen, die von dieser Einstellung nichts mitbekommt!

Dazu muss man einstellen:
Unter Windows: Rechtsklick auf Arbeitsplatz --> Eigenschaften --> Erweitert --> Umgebungsvariablen

In dem Fenster dann im oberen Block "Benutzervariablen" (wenn nur für diesen Nutzer) oder im unteren Block "Systemvariablen" (alle User des Rechners) "Neu" anklicken.
Das folgende Fenster braucht zwei Angaben:

Name der Variablen: http_proxy
Wert der Variablen: http://xxx.yyy.zzz.qqq:3128
(IP-Adresse des Rechners mit dem Cache drauf, wenn es der gleiche Rechner ist, ist das 127.0.0.1, und die Portadresse, also 3128 oder 3178, je nach dem, was man in der Squid.conf eingetragen hat.)
Mit OK bestätigen, sicherheitshalber neu starten.

unter Linux:

export http_proxy=http://xxx.yyy.zzz.qqq:3128
(Achtung, das habe ich nicht getestet!)

Was der Cache mitzieht, kannst du unter Linux recht schnell feststellen.
Öffne ein Terminalfenster und gibt folgenden Befehl ein:

tail -f /var/log/squid/access.log

Der Befehl zeigt dir fortlaufend aktualisiert das Zugriffslog des Squid an. jede Zeile ist eine Datei, auf die zugegriffen wird. Bei den Einträgen sind Lindenserver, wo z.B. Sidebar u.ä. gespeichert sind, die sind nicht interessant. Wichtig sind alle Einträge, die nach dem Schema agni.lindenlab.com:12046/<UUID>/cab/<UUID> aufgebaut sind - das sind die Texturen. (UUID: unique universal Identifier - diese grässliche lange Kette aus Zahlen und Zeichen...)

Falls dir das System den Zugriff per tail auf das Log verweigert, musst du entsprechend Berechtigungen auf die Dateien legen.

Nachtrag:
Mittlerweile hängen wir zu zweit auf dem Cache, das macht einigen Spaß.

Was man noch ändern kann:

cache_mem 2048 MB
Der Arbeitsspeicher, den Squid nutzen darf, um gecachte dateien im RAM vorzuhalten. Was da drin ist, braucht nicht von der lokalen Platte geholt werden. Wenn man genug RAM hat, kann man sich da was gönnen - RAM ist doch recht schnell...

maximum_object_size_in_memory 1024 KB
Die größte Dateigröße, die squid im Speicher halten darf, beträgt 1 MB (1024 KB). Größere Dateien werden immer auf die Platte ausgelagert und von dort geholt. Ich hab allerdings keine Textur im Clientcache gefunden, die 1024K groß war...
Bitte nicht mit "maximum_object_size" verwechseln - das ist die größte Dateigröße die überhaupt(!) gecached wird, dei sollte bitte auf 4096 KB bleiben.

storeurl_rewrite_children 48 (oder mehr...)
Auch das ist eine Speicherplatzfrage. Wenn genug RAM vorhanden ist, kann man - besonders bei mehreren Usern - mehr als 32 Childprozesse freigeben (Child-Prozess: Ein "Kind-Prozes", also ein Prozess, der von einem anderen Prozess gestartet wird. Prozess verstehe man hier vereinfacht als Programm. Squid startet also mit diesem Eintrag 48 mal das Rewrite-Programm. Kann man nachsehen: Unter Windows im Taskmanager --> Prozesse, unter Linux im Terminalfenster mit ps -A)

Die Cache-Maschine ist bei mir ein ca 5 Jahre alter Pentium-IV mit 4 GB RAM und einem "nackten" Ubuntu 10.10 mit Gnome Desktop. Auf irgendwelche Tricks mit IP-Adressen oder so habe ich verzichtet, "rein" und "raus" gehen über die gleiche GBit-Netzwerkkarte und -adresse. Da das DSL der limitierende Faktor ist, geht das erstmal so.
 
Ich behaupte einfach mal: die Lindens hat es schlicht bisher nicht interessiert, den Viewer dahingehend zu optimieren.

Das man die Proxyeinstellungen auch einfacher zugänglich machen kann zeigt ja der Phoenixviewer.

Eines der Ziele von HTTP-Texturen war neben dem Rauswurf des Overheads bei UDP mit dem homebrew-Protokoll auch, dass sie intern selber Proxyserver aufsetzen wollten - keine Ahnung ob schon geschehen - um so den Assetstore bei Texturanfragen noch mehr als bisher zu entlasten.
 
Soweit ich weis, setzt Linden schon lange den Squid als internen Zugriffscache ein, der Squid hat einen eigenen Modus dafür. Das ist prinzipbedingt nicht der optimalste Weg, da die Zugriffe bestenfalls SIM-bezogen sind. Der beste Weg wäre der direkte Zugriff auf die AmazonAWS-Cloud und ein funktionierender Cache im Viewer.

Ob es Linden nicht interessiert hat, oder ob es schlichtweg schlampig programmiert ist... wenn es sie nicht interessiert, warum gibt es dann überhaupt so eine Einstellung? Aber das ist letztlich ein Streit um des Kaisers Bart, Fakt ist, dass es bei den meisten Viewern (Siehe z. B. Kirsten S20, da ist das ebenso) nicht sauber implementiert ist.
 
Soweit ich weis, setzt Linden schon lange den Squid als internen Zugriffscache ein, der Squid hat einen eigenen Modus dafür. Das ist prinzipbedingt nicht der optimalste Weg, da die Zugriffe bestenfalls SIM-bezogen sind. Der beste Weg wäre der direkte Zugriff auf die AmazonAWS-Cloud und ein funktionierender Cache im Viewer.

Du meinst die Viewer sollten direkt auf die Cloud zugreifen und da die Texturen holen? Falls die Interpretation zutrifft: ich höre das Geschrei der Content Maker jetzt schon...
 
Ob ich die Textur von Linden abhole oder von AmazonAWS - wo bitte ist der Unterschied? Das ist die gleiche Datei!

Da zu zetern... dann kann ich auch über den Squid hier bei mir zetern, denn der speichert die Texturen nochmal. Und der Cache vom Viewer speichert sie auch nochmal, alles in meinem Vollzugriff.

Wenn ich das richtig in Erinnerung habe (hat mich nie interessiert) ist das im Cache eine unkenntlich gemachte JPG oder JP2000 Datei. Wer sich also den Spaß (?) macht, die Schlüsselung zu knacken, hat die Texturen direkt auf dem PC - im Viewer Cache. Ob die dann direkt aus der Cloud stammen, oder ob ein Lindenserver sie erst aus der Cloud lädt und dann an mich weiterschickt, ist dafür so was von wumpe....

Das einzige wirkliche Risiko, dass ich sehe: Mit dem direkten Zugriff könnte (!) sich ein Einfallstor in die Cloud öffnen, über das man mehr ziehen kann. Aber auch das ist eher theoretisch. Wenn das so wäre, wäre die Amazon-Cloud ziemlich leer, weil viel zu unsicher. Gott sei Dank ist da neben Linden ja noch der Cloud Betreiber involviert, der entsprechende Sicherheitskonzepte haben dürfte - sonst wäre er nämlich pleite ;)

Da Texturen als reiner HTTP-Zugriff erschlagen werden, könnte man hier einen eigenen Zugang konzipieren, der eben nur Texturen liest und lesen kann. Schlimmstenfalls könnte jemand das knacken und Texturen auslesen. Was hat er dann? Genau das, was im Viewercache oder im Squid cache sowieso lokal abgelegt ist. So what?


Die Sicherheitsprobleme, auch und grade was Content angeht, gehen sehr viel tiefer, daran würde ein direkter DL aus der Cloud wenig bis gar nichts ändern. Da muss Linden den Hebel ansetzen und das sehr tief im System - was man nicht gerne tun wird, denn das bedeutet hochgradig verschlüsseln - bei einigen tausend Texturen per SIM wird das ein prozessorintensives Verfahren, und auch mancher PC zuhause, der SL "grade noch so" packt, wird dann den Löffel abgeben.
 
Wenn ich das richtig in Erinnerung habe (hat mich nie interessiert) ist das im Cache eine unkenntlich gemachte JPG oder JP2000 Datei. Wer sich also den Spaß (?) macht, die Schlüsselung zu knacken, hat die Texturen direkt auf dem PC - im Viewer Cache.

Das ist nicht wirklich eine unkenntlich gemachte jpeg2000 datei, da werden lediglich Header und Body getrennt gespeichert um besser auf die Datenbank zugreifen zu können. Das ist also nicht unkenntlich gemacht, das Protokoll für den Cache ist sogar frei verfügbar: Texture Cache - Second Life Wiki

Es gab auch mal die Diskussion über einen verschlüsselten Cache. Das wurde aber recht schnell wieder verworfen, denn zum einen kostet das ziemlich Performance und zum anderen muss aus den jpeg2000 Dateien sowieso vom Viewer ein Bitmap für die Grafikkarte gemacht werden.
Und wer es schafft aus den verschiedenen Dateien für Header und Body im Cache wieder Texturen zu basteln, der kann wohl auch die Bitmaps aus dem Viewer auslesen.

Ausserdem ist es dank OpenGL auch kein Problem die Texturen notfalls direkt aus der Grafikkarte zu holen. Dafür muss man überhaupt nicht programieren können, OpenGL Grundkenntnisse und das entsprechende Programm bzw. eine entsprechende Schnittstelle reichen.
 
Oder so. Stimmt, OpenGL hatte ich dabei ncoh glatt übersehen.

Eine Verschlüsselung würde auf beiden Seiten die Performance in die Knie zwingen. Der Server müsste im Extremfall einige hundert oder mehr Texturen für 40 Avas verschlüsseln können, der Client muss das wieder auspacken können - und an der Stelle könnte man wieder "fündig" werden. Solange da kein Datenstrom wie beim verschlüsselten HDMI gemacht wird (für ein Computergame ziemlich tödlich, da das kaum ein normaler Monitor beherrscht), sehe ich da keine realisierbare Lösung.
 
Stehlen wird man immer können, ist nur eine Frage des Aufwands und der kriminellen Energie. Und selbst wenn man den Cache verschlüsselt, dann dauerts nur paar Wochen dann gibts das erste Tool was es entschlüsselt. Außer Spesen dann nix gewesen. Das Geld kann man dann auch sinnvoller investieren. Aber wir kommen ab vom Thema.

Bei mir läuft der Squid optimal. Bin zufrieden. Ist nur interessant zu beobachten was da durch die Leitung muss. Mit komplett gelöschten Caches (Squid + Viewer) mußten bei Login danach erstmal ca. 50-100 MB an Texturen geladen werden, ohne das sich der Avatar überhaupt bewegt hat damit alles im Umfeld (Sichtweite 160) richtig dargestellt war.
 
Alles wieder auf Anfang!
Nun, funzt alles wieder wie beim ersten Versuch. Ich habe mich irritieren lassen von der Web-Umleitung. Unter Ubuntu ist die gar nicht weiter nötig, weder mit export noch im Viewer. In der access.log wird mir angezeigt welche Textur verworfen und welche der Cache annimmt, im store.log was mit der Textur gemacht wird. Alles wunderbar.
Nun habe ich noch einen memory cache eingerichtet und der sollte nicht all zu hoch sein. 64MB sind schon ausreichend um das Ganze mehr auf Trab zu bringen. Die Inhalte werden im Speicher gar nicht lange vorgehalten.

Ich verwende einen AMD Athlon64 3200+ mit 2GB Ram und einer GF 9800GT 1GB, Ubuntu 10.04, Phoenix 908

Mit der alten Rübe macht jetzt SL mit einem FPS zwischen 12 und 36 mehr Spaß. Das ist gut das 5fache wie ohne squid :)
 
Trotz Einstellung der Benutzervariablen in Windows wird nichts in den cache von squid geschrieben. Ich hab jetzt die Nase voll von squid, schien so einfach, naja.. vergessen.


Zu Texturenklauen btw:

(Shirley Iuga: "Ausserdem ist es dank OpenGL auch kein Problem die Texturen notfalls direkt aus der Grafikkarte zu holen. Dafür muss man überhaupt nicht programieren können, OpenGL Grundkenntnisse und das entsprechende Programm bzw. eine entsprechende Schnittstelle reichen.")

Es scheint, man braucht nicht mal OpenGL Grundkenntnisse, ausser das man weiss, das es existiert. Aber das Prog, welches texturen aus OpenGL abgreift, laueft nur bis Windows XP und ist schon eine Raritaet. Und wer von den Gelegenheitsinteressierten bleibt noch bei XP? Schnuppern in Foren laesst vermuten: da wird so bald nichts neues kommen. 2 oder 3 mal jammerte da einer, das es nur noch unter XP laueft, und das ist ewig her...und das feedback ist nahezu null. Ich denke, da ist kaum Gefahr aus der Ecke.
 
Es scheint, man braucht nicht mal OpenGL Grundkenntnisse, ausser das man weiss, das es existiert. Aber das Prog, welches texturen aus OpenGL abgreift, laueft nur bis Windows XP und ist schon eine Raritaet. Und wer von den Gelegenheitsinteressierten bleibt noch bei XP? Schnuppern in Foren laesst vermuten: da wird so bald nichts neues kommen. 2 oder 3 mal jammerte da einer, das es nur noch unter XP laueft, und das ist ewig her...und das feedback ist nahezu null. Ich denke, da ist kaum Gefahr aus der Ecke.

Ich muss dich leider enttäuschen - diesen OpenGL Debugger gibt es mittlerweile schon als 1.0 Beta 01 sowohl als 32 bit als auch als 64bit Version (zum Debuggen von 32 bit bzw. 64 bit Programmen). Nur eben nicht auf der alten "Hauptseite"des Programms, sondern in einem Code Repository bei einem großen Hoster. Und die letzte Version ist vom 20.Januar 2011.

Aber das schöne ist: Nicht nur böse Copybotter können dieses Tool nutzen um Texturen zu kopieren und diese als eigene nach SL hoch zu laden, damit kann man auch direkt einen Copybotter überführen, z.B. wenn man in seinen Texturen irgendwo Watermarks und/oder sonstige spezielle Kennzeichnungen versteckt hat...
 
Kein Werkzeug ist von sich aus gut oder böse.
Gut oder Böse ist immer die Hand, die das Werkzeug führt.
 
Stehlen wird man immer können, ist nur eine Frage des Aufwands und der kriminellen Energie. Und selbst wenn man den Cache verschlüsselt, dann dauerts nur paar Wochen dann gibts das erste Tool was es entschlüsselt. Außer Spesen dann nix gewesen. Das Geld kann man dann auch sinnvoller investieren. Aber wir kommen ab vom Thema.

Bei mir läuft der Squid optimal. Bin zufrieden. Ist nur interessant zu beobachten was da durch die Leitung muss. Mit komplett gelöschten Caches (Squid + Viewer) mußten bei Login danach erstmal ca. 50-100 MB an Texturen geladen werden, ohne das sich der Avatar überhaupt bewegt hat damit alles im Umfeld (Sichtweite 160) richtig dargestellt war.

Wie gesagt, nach etlichem Hickhack und Mehrkampf im Squid.conf-Ändern rennt er bei mir auch, auf einer externen Linuxdose als Cache für mehrere User.

In der Tat ist es interessant, das mal zu beobachten - vor allem, wie erschreckend langsam Texturen teilweise selbst bei einem 16MBit-DSL (Gemessen real 11-12MBit) getröpfelt kommen. Da merkt man dann schon, wieviele Leute winzige Vendorenfensterchen mit 1024er Auflösung beschicken....

Wenn es technisch geht, würde ich schon mehr als 64 MB freigeben und die Maximalgröße von Objekten, die im Speicher bleiben dürfen entsprechend mit hochsetzen. Viele Texturen sind schon um 250 - 500 KB groß (Nachsehen im Ttexturencache des Viewers, da sieht man das recht gut.). Wenn ich mir die access.log online anzeigen lasse (tail -f /var/log/squid/access.log unter Linux), sieht man recht gut, was unter "TCP-HIT" läuft (Kommt aus der Festplatte) und was unter "TCP-MEM-HIT" läuft - das kommt aus dem Speicher. Bei einer dicht bepflanzten und bewaldeten SIM und zwei Usern kommt bei mir doch ein großer Teil aus dem Memory - es reicht, sich umzudrehen.
 
Ich muss dich leider enttäuschen - diesen OpenGL Debugger gibt es mittlerweile schon als 1.0 Beta 01 sowohl als 32 bit als auch als 64bit Version (zum Debuggen von 32 bit bzw. 64 bit Programmen). Nur eben nicht auf der alten "Hauptseite"des Programms, sondern in einem Code Repository bei einem großen Hoster. Und die letzte Version ist vom 20.Januar 2011.

Nasowas... ne, so entaeuschend ist das auf der anderen Seite auch nicht, der handelsuebliche Internetgoogler mit gemaessigtem Interesse, der nicht mal weiss, was ein "Code Repository" ist, wie ich, findet das wohl nicht. Ist auch ne gute Nachricht, lol. (... sucht...)
 
Der Normal-User nicht. Aber jemand,d er sich mehr mit dem Thema beschäftigt, vermutlisch schon. und dazu gehört jemand, der einen CopyBViewer bauen kann, mit ziemlicher Sicherheit ;)
 
Ich überlege ob ich mir die Arbeit mache und mir auf einem Rootserver noch einen Parent-Proxy aufsetze. Damit holt er das direkt mit 100MBit und reicht es dann nur durch. Den könnte man auch mit Freunden teilen, damit würden (deren) Texturen schonmal nicht aus Übersee geladen sondern vom fixen deutschen Standort. Oder macht das Probleme wenn die Zugriffe von einer völlig andere IP komme als der Viewer selbst?
 
Keine Ahnung... aber für den Zweck dürfte Amazon EC2 prima zum Testen sein. Eine Small Instanz zu mietet kostet die Stunde knapp 8 Cent, für erste Zwecke obs geht oder nicht reicht das sicher völlig aus und gräbt einem wirklich kein zu tiefes Loch in den Geldbeutel.
 

Users who are viewing this thread

Zurück
Oben Unten