URL: https://www.overclockers.at/internet-provider/apache-bandbreitenproblem-mit-upc-shdsl-spannend_231195/page_1 - zur Vollversion wechseln!
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:
haha, ich liebe deine labor-aufgaben 
klingt komisch... kannst mal einen link geben zum testfile downloaden
was wirklich heisses kommt mir auch nicht auf die schnelle in den sinn, würde mich als erstes mal mit den keepalive/process creation/spare threads settings des apache spielen
(sendfile kannst übrigens auch nur für gewisse ordner abschalten => schon probiert ein file mit und eins ohne sendfile off zu laden?)
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.
ich schaff gleich nur 300kb - die dafür konstant
sehr komisches problem was du da hast hast in den configs ev irgendwo ne limitierung drinnen?
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.
mit einem download hab ich 460 erreicht, mit zwei ~400 + 330 die aber dann auf 2x 300 abgesunken sind (ich schätz das war dann der crusher der mir in die quere gekommen ist )
sry, wollte da kein mini-ddos initialisieren
Aber man sieht schon, es ist reproduzierbar.. Ich habs ja auch schon von mehreren schnellen Hosts aus probiert.. und kanns mir einfach nicht erklären.
Edit: Falls es interessiert, hier die verbauten NICs:
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.
Genau, hab ich getestet weil ich genau sowas schon vermutet hatte.. Was ohnehin eine Frechheit gewesen wäre bei meiner Leitung..
Aber vielleicht is ja noch irgendein Blödsinn am SHDSL Extender eingestellt? Ich denke als nächstes setz ich schnell einen Miniwebserver auf meinem Laptop auf und probiers damit, so ließe sich die Line wohl wenigstens ausgrenzen.
Edit: Hab Mal schnell den AnalogX SimpleWWW probiert, bringt auch nicht viel. Der ist durch die Bank etwas lahmer, aber das grundsätzliche Verhalten ist sehr ähnlich! 4MB/s ca. im LAN und 350kb/s ca. pro Conn im WAN.
Dürfte also nicht am Apache liegen! Der Hund muß woanders begraben sein.
Edit 2: Zur Abwechslung nochmal Port 81 probiert, nur um ganz sicher zu gehen. Aber: Same shit.
Kriegst du ueber andere Protokolle (FTP *grusel* oder z. b. plain TCP via netcat) mehr ueber eine einzige outbound-Verbindung ins WAN?
FTP (plain), FTP+SSL (implicit wie auch explicit), SSH2/SCP, alle schaffen mit einer Single Connection um die 950-980kB/s, und mehr gibt die Line eh ned her.. Bei SCP und FTPS ist halt die CPU Last tlw. bis zu 50% auf einem Kern. Aber das scheint bei den Protokollen kein Problem darzustellen.
Wie gesagt, CPU Bottleneck scheints keines zu geben. Im LAN kommen sowohl FTP+SSL als auch HTTPS auf ca. die gleichen Transferraten um die 3MB/s. Da dürften die CPUs dann abriegeln.
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.
So, getestet mitm Notebook direkt am SHDSL Extender, und gleiches Verhalten wie am Server. Das legt nahe, daß ich dieses Mal zum Glück meine Konfigurationen als Fehlerquelle ausschließen können sollte. Es scheint also am "Kastl" zu liegen.
Werde ggf. noch mehr testen, aber vorerst schauts Mal stark danach aus, daß entweder die SHDSL Extender Konfig im ***** is, oder UPC sonst was komisches gedreht hat hier.
Edit: Nochn bissl mehr rumgespielt, und je mehr ich rumspiele, desto mehr erwächst in mir die Gewißheit, daß sich das Notebook als Behelfsserver genauso verhält wie mein guter alter PPRO Panzer, der wohl somit wirklich unschuldig sein dürfte.. Auch Apache erhält damit eindeutig den Freispruch, er kann glaub ich ned das mindeste dafür.
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2024