Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Reuther Newsgroups: de.comp.lang.javascript Subject: Re: HTTP POST? Date: Tue, 11 Jun 2019 17:50:40 +0200 Lines: 62 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Trace: individual.net MDU/JWH4Ll2+Ql67muWVHwELZk7wG2n4gcOR7LS7q/td+F+zex Cancel-Lock: sha1:7KlEG9uagFEACnkpUFa84pE8CWM= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Hamster/2.1.0.1538 In-Reply-To: Xref: csiph.com de.comp.lang.javascript:5113 Am 10.06.2019 um 11:47 schrieb Ulli Horlacher: > Stefan Reuther wrote: >> Am 09.06.2019 um 14:06 schrieb Ulli Horlacher: >>> Stefan Reuther wrote: >>>>> Ok, dann ist das Projekt gestorben. "Geht halt nicht". >>>> >>>> Natürlich geht das. Mit Einschränkungen. Die wichtigste Einschränkung >>>> dabei: du kannst nicht beeinflussen, wann und wie oft der Browser eine >>>> Verbindung aufbaut und wie lange er dazu benötigt. >>> >>> Und eben damit geht eine genaue Durchsatzmessung nicht, weil die vielen >>> HTTP-connects overhead das Messergebnis verfaelscht. >> >> Deswegen parallel. > > Das macht es nicht (viel) besser. > Jeder HTTP connect dauert vieeeeeeeeeeeeeeeel laenger als das Uebertragen > von Daten. Vermutet oder gemessen? Und insbesondere: gemessen im Kontext eines Browsers? Ein HTTP-Connect ist ein TCP-Verbindungsaufbau (3 Pakete) + die Requestdaten. Wirklich langsam wird das eigentlich alles nur, wenn du z.B. irgendwelche Randfälle von Nagle's Algorithm o.ä. triffst, wo eine Seite erst einen Timeout oder ACK abwartet, bevor sie sich traut, ein Folgepaket zu schicken. Und all das lässt sich durch Vergrößerung der Datenmenge reduzieren. Mehr Daten in der Payload = Kernel hat immer was zu senden = Overhead geht besser unter. >> Fehlkonfigurationen ausgenommen wird kein Browser der letzten 20 Jahre >> wirklich für jeden Request eine neue Verbindung aufbauen. > > Wenn ihm das die Gegenseite vorschreibt, schon. > Da gibts mehrere Moeglichkeit. Eine davon waere ein Proxy. > Oder mein tcpbm Server. Ich gehe natürlich von einem angepassten Server aus. Also keinem, der bei so einem Benchmark-Request erst das CGI vom NFS startet. >>>> Aber die genaueste Messung, um rauszubekommen, wie lange eine >>>> Dateiübertratung mit F*EX aktuell dauert, ist ja eh immer noch, mit F*EX >>>> eine Datei zu übertragen und zu schauen, wie lange das dauert. >>> >>> NOCHMALS: das hat NICHTS mit F*EX zu tun! >> >> Mag ja sein, aber wir reden von Endusern? Wenn ich Probleme mit der >> HTTP-Download-Geschwindigkeit von Server X hab, pack ich nicht gleich >> das Profi-Bandbreiten-Messgerät aus, sondern messe erstmal die >> HTTP-Download-Geschwindigkeit von Server Y, um auf "mein Ende" oder "X's >> Ende" einzugrenzen. > > Die Upload Geschwindigkeit kann um Faktor 100 von der des Dowmloads > abweichen. Deshalb brauch ich ein Tool, das beides kann. Wenn ich Probleme mit der Upload-Geschwindigkeit hab, mach ich das selbstverständlich ganz genauso. Stefan