Apache Bandbreitenproblem mit UPC SHDSL: Spannend..

Ich hatte ja schon einmal ein Bandbreitenproblem mit Apache, das ließ sich allerdings durch Deaktivieren der sendfile() Funktion über die Config beheben. Nun habe ich ein viel spannenderes Problem, und ich komm einfach nicht dahinter was es sein könnte. Also..

LAN Bandbreite: 100/100MBit/s.
WAN Bandbreite: 8/8Mbit/s.

Im LAN komme ich mit Plain HTTP für einen einzelnen Download vom Server auf einen Durchsatz von ca. 5.5MB/s und mit SSL auf ca. 3.8MB/s, was ich absolut ok finde.

Im WAN allerdings gibt mir der Server pro Connection nur ca. 480-490kB/s, für mich unverständlich. Der Witz: Wenn ich eine ZWEITE Verbindung zum Webserver öffne und mit 2 Verbindungen gleichzeitig sauge, schaffe ich es, die 8/8MBit Leitung auszulasten. Pro Connection kriege ich ca. die halbe Bandbreite der Line.

Ich dachte mir zuerst vielleicht ists ein CPU Bottleneck (200MHz PPRO), sodaß ich mehrere Threads am Server brauche, um die Leitung auszureizen, also hab ich die CPU Last überwacht, die ist aber geradezu lachhaft minimal. Der Apache lastet beim Saugen nicht Mal eine CPU annähernd aus, das ist so bei 20-30% Load auf einem Kern.

Connections per SSH2 oder FTP+SSL (AES256) schaffen sogar locker die volle Bandbreite der Line, natürlich mit weit höherer CPU Last, aber sie schaffens.

Was kann hier schief gewickelt sein?! Im LAN funktionierts ja mit sehr hohem Speed, nur im WAN wills ned.

Auf meinen Router habe ich übrigens keinen Zugriff, ist ein Paradyne/Zhone SNE2040G von der UPC.

Habe den Server schon testweise auf andere Ports lauschen lassen, das hats nicht gebracht.

Jetzt könnte man natürlich auch meinen "muß an der Line liegen", aber ohne fundierte Belege kann ich mir den Anruf bei der UPC wohl in die Haare schmieren...

Config:

• Win2000 Server
• WAN IF: Intel PRO/1000 GT PCI
• LAN IF: 3Com Etherlink XL 10/100 PCI
• Apache 2.2.21 (sendfile function off)
• Winroute FW, keine HTTP Inspection
• 4 x 200MHz 1MB PPRO
• 2GB RAM (ca. 1GB frei)
• SCSI Storage Subsystem mit mehr als genug Leistung.

IRGENDeine Idee?

Edit: Der Cap am WAN Interface betrifft sowohl plain HTTP als auch HTTPS in exakt gleicher Weise.

Mit aktivem Sendfile capped er auf ~350kB/s auf LAN und WAN. Daher global abgeschaltet, dann hab ich den hohen Speed im LAN und besagte ~490kB/s pro Connection im WAN.

Hier ein [Testfile zum Download]. Ist ein Videostream, der unter CC Lizenz steht (Elephant's Dream Movie).

Den Download sollte man etwas laufen lassen um den Speed zu evaluieren. Da der Server aktiv ist, kanns ja sein, daß auch andere User grad was machen, wobei's momentan recht idle aussieht.

Nein. Sonst würds ja auch im LAN nicht mit >5Mbyte pro Sekunde gehen.

Übrigens wärs gut, wenn jeder der das Testfile saugt das hier ankündigt, weil auch mit dem Problem ist die Leitung sehr schnell ausgelastet, sobald das mehrere gleichzeitig versuchen.

Wenn nur einer auf einmal testet, ließe sich auch das Verhalten reproduzieren, daß die totale Bandbreite steigt, wenn dieser User zwei Conns aufmacht und das File parallel saugt.

sry, wollte da kein mini-ddos initialisieren

BW-Shaping vom WAN-Provider bei nur einem TCP-Stream auf Port 80 vielleicht? Schon mal auf einem Nonstandard-Port probiert?

Edit: ah, ueberlesen. Wurde schon erfolglos probiert.

Kriegst du ueber andere Protokolle (FTP *grusel* oder z. b. plain TCP via netcat) mehr ueber eine einzige outbound-Verbindung ins WAN?

Interessant, hab auch 2x440 Kilobyte / Sekunde.
Klingt nach shaping, über eine Verbindung um die 450-470 Kilobyte / Sekunde.

Über welchen Port das ganze rennt wird keine Rolle spielen wenn sie wirklich shapen wollen, kann ich mir bei einer Business Leitung aber schwer vorstellen.