ubuntuusers.de

Ich betreibe einen Proxy-Server auf den in Hochzeiten zeitgleich ca. 30 Personen zugreifen. Surfen im Internet ist überhaupt kein Problem allerdings kommt es bei Seiten mit Java zu starken Verzögerungen bis hin zu einigen Minuten. Rufe ich als einzelner eine Seite mit Java-Applets auf ist die Ladezeit im normalen Bereich von mehreren Sekunden, wobei ja auch die JVM gestartet wird.

Meine erste Vermutung war, dass Squid die Java-Applets nicht cached, allerdings ist die Konfiguration was den Cache betrifft noch default, d.h. maximum_object_size steht immer noch bei 4096 kB, was mMn selbst bei Java ausreichen sollte. Ich bin im Moment ein wenig ratlos, vielleicht hat von euch ja noch jemand eine Idee, an welcher Schraube man drehen kann bzw. woran es liegt.

Der Server ist ein PIII mit 192 MB Hauptspeicher, der aber weder von CPU- noch RAM-Belastung überfordert ist, daran kann es also auch nicht liegen.

Gruß Cermit

Schau dir mal beim Aufruf der Seiten die /var/log/squid/access.log an bzw. poste mal ein paar Auszüge.

So, hab jetzt mal ein wenig experimentiert. Ich habe eine Seite mit Firefox aufgerufen und danach nochmal mit dem IE, um zu sehen, ob er die Dateien aus dem Cache des Proxys holt. Hier die access.log dazu:

1224243360.282    218 192.168.1.48 TCP_MISS/200 7390 GET http://www.realmath.de/Neues/Klasse6/brueche/bruchteile.html po DIRECT/82.165.93.236 text/html
1224243360.430    148 192.168.1.48 TCP_MISS/200 9356 GET http://www.realmath.de/Neues/Klasse6/brueche/bruchteile.js po DIRECT/82.165.93.236 application/x-javascript
1224243401.499    187 192.168.1.48 TCP_MISS/200 4712 GET http://www.realmath.de/Neues/Klasse6/brueche/bruchteil.ggb po DIRECT/82.165.93.236 text/plain
1224243422.659    199 192.168.1.48 TCP_MISS/200 8149 GET http://www.realmath.de/Neues/Klasse6/bruchteil/brucherstellen.html po DIRECT/82.165.93.236 text/html
1224243422.807    147 192.168.1.48 TCP_MISS/200 8312 GET http://www.realmath.de/Neues/Klasse6/bruchteil/brucherstellen.js po DIRECT/82.165.93.236 application/x-javascript
1224243438.133    126 192.168.1.48 TCP_MISS/200 2709 GET http://www.realmath.de/Neues/Klasse6/bruchteil/brucherstellen2.ggb po DIRECT/82.165.93.236 text/plain
1224243438.191    158 192.168.1.48 TCP_MISS/200 3839 GET http://www.realmath.de/Neues/Klasse6/bruchteil/brucherstellen1.ggb po DIRECT/82.165.93.236 text/plain
1224243473.076      1 192.168.1.48 TCP_DENIED/407 1965 GET http://www.realmath.de/Neues/Klasse6/bruchteil/brucherstellen.html - NONE/- text/html
1224243477.629      1 192.168.1.48 TCP_MEM_HIT/200 8156 GET http://www.realmath.de/Neues/Klasse6/bruchteil/brucherstellen.html po NONE/- text/html
1224243477.655     26 192.168.1.48 TCP_HIT/200 16253 GET http://www.realmath.de/css/global.css po NONE/- text/css
1224243478.973      1 192.168.1.48 TCP_MEM_HIT/200 8319 GET http://www.realmath.de/Neues/Klasse6/bruchteil/brucherstellen.js po NONE/- application/x-javascript
1224243479.016     44 192.168.1.48 TCP_MEM_HIT/200 1819 GET http://www.realmath.de/bilder/home.gif po NONE/- image/gif
1224243479.030     10 192.168.1.48 TCP_MEM_HIT/200 1841 GET http://www.realmath.de/bilder/mathe.gif po NONE/- image/gif
1224243541.466    108 192.168.1.48 TCP_CLIENT_REFRESH_MISS/304 300 GET http://www.realmath.de/Neues/Klasse6/bruchteil/brucherstellen1.ggb po DIRECT/82.165.93.236 -
1224243541.540     73 192.168.1.48 TCP_CLIENT_REFRESH_MISS/304 300 GET http://www.realmath.de/Neues/Klasse6/bruchteil/brucherstellen2.ggb po DIRECT/82.165.93.236 -

So, wie ich das interpretiere cached er das javascript brucherstellen.js aber nicht die eingebundenen Dateien brucherstellen1.ggb. Bei einer anderen Seite cached er die Klassen nicht:

1224244724.230    633 192.168.1.48 TCP_MISS/200 2515 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/SolarApplet.html po DIRECT/128.97.154.196 text/html
1224244739.636    226 192.168.1.48 TCP_MISS/200 5224 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/SolarApplet.class po DIRECT/128.97.154.196 application/x-java-applet
1224244739.891    215 192.168.1.48 TCP_MISS/200 2987 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/Planet.class po DIRECT/128.97.154.196 application/x-java-applet
1224244740.149    214 192.168.1.48 TCP_MISS/200 1353 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/Moon.class po DIRECT/128.97.154.196 application/x-java-applet
1224244740.377    212 192.168.1.48 TCP_MISS/200 1271 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/RingPlanet.class po DIRECT/128.97.154.196 application/x-java-applet
1224244740.692    213 192.168.1.48 TCP_MISS/200 1547 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/SolarApplet$SymMouse.class po DIRECT/128.97.154.196 application/x-java-applet
1224244740.946    213 192.168.1.48 TCP_MISS/200 2466 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/StarTrek.class po DIRECT/128.97.154.196 application/x-java-applet
1224244773.240      1 192.168.1.48 TCP_MEM_HIT/200 2522 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/SolarApplet.html po NONE/- text/html
1224244788.528    222 192.168.1.48 TCP_CLIENT_REFRESH_MISS/304 498 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/SolarApplet.class po DIRECT/128.97.154.196 -
1224244788.752    222 192.168.1.48 TCP_CLIENT_REFRESH_MISS/304 492 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/Planet.class po DIRECT/128.97.154.196 -
1224244788.974    221 192.168.1.48 TCP_CLIENT_REFRESH_MISS/304 490 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/Moon.class po DIRECT/128.97.154.196 -
1224244789.192    218 192.168.1.48 TCP_CLIENT_REFRESH_MISS/304 496 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/RingPlanet.class po DIRECT/128.97.154.196 -
1224244789.428    236 192.168.1.48 TCP_CLIENT_REFRESH_MISS/304 507 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/SolarApplet$SymMouse.class po DIRECT/128.97.154.196 -
1224244789.648    219 192.168.1.48 TCP_CLIENT_REFRESH_MISS/304 494 GET http://www.humnet.ucla.edu/humnet/french/faculty/gans/java/StarTrek.class po DIRECT/128.97.154.196 -
1224244824.554    296 192.168.1.48 TCP_MISS/200 498 GET http://www.humnet.ucla.edu/favicon.ico po DIRECT/128.97.154.196 image/x-icon

Das erklärt, warum das ganze so lange dauert, aber wie kann ich das Problem beheben?

Gruß Cermit

Hat jemand noch eine Idee?

Gruß Cermit

Im Squid kannst du irgendwo angeben welche minimale Größe ein Objekt haben muss. Scheinbar sind die Objekte zu klein. Schau evtl. auch noch ob du vielleicht ein Konfigurationsproblem für DNS hast, ein beliebter Squid-Fehler.

Danke erstmal für die Antwort. Ich habe gerade nochmal in der squid.conf nachgeguckt. Der Wert für die minimale Objektgröße (minimum_object_size) ist bei 0 KB, es sollte also eigentlich alles gecached werden. Der maximale steht bei 4096 KB.

Auf deinen Hinweis, dass es sich um ein DNS-Problem handeln kann habe ich die Eintragungen bzgl. DNS angeguckt. Die Konfigurationsdatei von squid nimmt standardmäßig die eingetragenen Server aus der resolv.conf. Dort sind aktuell folgende Server eingetragen:

217.237.148.70 217.237.150.115

Das sind zwei aktuelle Nameserver von T-Online. Die Namensauflösung funktioniert von der Konsole aus, eine ping auf www.heise.de wird richtig aufgelöst. Komischerweise kann ich die Nameserver direkt nicht anpingen.

Noch eine weitere Idee?

Edit: Hab mich selbst nochmal auf die Suche gemacht bzgl. Namensauflösung und bin auf folgenden Beitrag gestoßen, der ggf. genau meinem Problem entspricht:

This *might* be the same problem as I encountered recently, that in our case (squid-2.6.STABLE17, no authentication) caused very slow loading of applets. Here is the record from our task log that shows what we did to fix it. Hope it helps.

"The delay was observed in Wireshark traces to be due to unsatisfied netbios name -service requests from client to proxy. Googling "netbios name java applet proxy" found chatter regarding known bugs in Java 5 still present in Java 6. The applet loader attempts to do a reverse lookup of a source host ip. It attempts firstly using DNS. That fails for our proxies as they are not in DNS. The applet loader then tries to resolve using netbios name services, but instead of using the WINS server specified for the PC's interface in the MSWindows Networking setup, it attempts to use the proxy, on which there is no netbios server, hence long delays due to request timeouts. The two possible workarounds are a) configure the proxies in internal DNS or b) install Samba netbios services on the proxies. The former is vastly easier and better and was immediately successful."

Jetzt stellt sich für mich die Frage, was genau mit

configure the proxies in internal DNS

gemeint ist. Die Namensauflösung im internen Netzwerk wird über einen Win2003-Server geregelt. Muss ich dort den Proxy eintragen und wenn ja, wo?

Gruß Cermit