Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.javascript > #5044 > unrolled thread
| Started by | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| First post | 2019-05-31 18:04 +0000 |
| Last post | 2019-06-11 11:57 +0200 |
| Articles | 20 on this page of 81 — 8 participants |
Back to article view | Back to de.comp.lang.javascript
HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-05-31 18:04 +0000
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-05-31 21:03 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 13:18 +0200
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-01 14:15 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 14:34 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 14:37 +0200
Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-01 15:11 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 15:44 +0200
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-01 16:07 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 20:17 +0200
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-01 18:43 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 20:19 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 22:45 +0200
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-02 05:02 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-02 18:05 +0200
Re: HTTP POST? Claus Reibenstein <4spamersonly@kabelmail.de> - 2019-06-02 09:37 +0200
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-02 13:39 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-02 18:12 +0200
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-02 04:06 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-02 18:22 +0200
Re: HTTP POST? Jan Novak <repcom@gmail.com> - 2019-06-03 14:54 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-02 10:44 +0000
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-02 14:00 +0200
Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-02 17:14 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-02 21:02 +0000
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-03 00:06 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-03 00:47 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-03 06:06 +0000
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-03 18:43 +0200
Re: HTTP POST? Claus Reibenstein <4spamersonly@kabelmail.de> - 2019-06-03 12:38 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-03 15:51 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-03 20:26 +0000
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-04 19:31 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-05 06:09 +0000
Re: HTTP POST? Claus Reibenstein <4spamersonly@kabelmail.de> - 2019-06-04 21:48 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-05 06:14 +0000
Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-03 18:34 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-03 20:31 +0000
Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-04 18:09 +0200
Re: HTTP POST? Manfred Haertel <Manfred.Haertel@rz-online.de> - 2019-06-05 05:50 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-05 06:30 +0000
Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-05 15:07 +0200
Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-05 18:09 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-05 20:25 +0000
Re: HTTP POST? Claus Reibenstein <4spamersonly@kabelmail.de> - 2019-06-06 09:49 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-06 08:47 +0000
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-08 14:53 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-08 19:31 +0000
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-08 14:50 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-08 19:34 +0000
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-09 00:45 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-10 17:29 +0200
Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-09 11:10 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-09 12:06 +0000
Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-10 11:16 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-10 09:47 +0000
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-10 20:35 +0200
Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-11 17:50 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-11 20:02 +0000
Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-12 07:45 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-12 06:08 +0000
Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-12 10:16 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-12 09:05 +0000
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-12 10:37 +0200
Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-12 18:14 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-12 21:28 +0000
Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-12 23:55 +0200
Re: HTTP POST? Manfred Haertel <Manfred.Haertel@rz-online.de> - 2019-06-13 05:35 +0200
Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-13 07:40 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-15 18:33 +0200
Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-14 18:08 +0200
Re: HTTP POST? Claus Reibenstein <4spamersonly@kabelmail.de> - 2019-06-10 17:37 +0200
Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-10 16:31 +0000
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-10 21:45 +0200
Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-10 22:04 +0200
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-11 00:23 +0200
Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-11 00:33 +0200
Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-11 01:01 +0200
Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-10 20:24 +0200
Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-11 10:48 +0200
Re: HTTP POST? Claus Reibenstein <4spamersonly@kabelmail.de> - 2019-06-11 11:57 +0200
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| Date | 2019-06-05 06:30 +0000 |
| Message-ID | <qd7nig$5go$3@news2.informatik.uni-stuttgart.de> |
| In reply to | #5079 |
Stefan Reuther <stefan.news@arcor.de> wrote: > Am 03.06.2019 um 22:31 schrieb Ulli Horlacher: > > Stefan Reuther <stefan.news@arcor.de> wrote: > >> Bei welcher Anwendung kommt es denn darauf an, ob man 1 GBit/s oder 10 > >> GBit/s hat? > > > > Filetransfer. > > Und da willst du adaptiv dem Nutzer je nach Bandbreite eine andere Datei > geben, oder wozu must du a priori die Bandbreite wissen? Ich bin der Admin. Ich geb den Usern keine Dateien. Die geben die sich gegenseitig. Aber wir wollen wissen, ob und wo es einen Flaschenhals gibt. Testen und Monitoring ist notwendig fuer einen professionellen Betrieb. Dazu gehoert auch, dass die User selber testen koennen. Der typische DAU kann aber nur seinen Webbrowser bedienen. Dem kann man kein CLI tool geben. > Filetransfer ist für mich was, das stoße ich an, und irgendwann ist es > fertig, und wenn die Übertragung mit 90% Wirespeed läuft, freu ich mich. Und wenn es nur 0.9% ist, moechte man wissen, woran es liegt. Da kann es viele Ursachen geben. Deshalb muss man vielen Stellen messen koennen. Eine davon ist die (reine) Uebertragungsgeschwindigkeit. > > root@fex01:~# tcpbm flupp.belwue.de > > sent: 19752 MB in 10 s = 1975 MB/s > > received: 23124 MB in 10 s = 2312 MB/s > > > > Das sind HTTP GET und POST. > > Nix websocket. > > > > Aber halt Perl und nicht Javascript. > > Perl mit einem eigenen direkt kontrollierbaren HTTP-Stack vermutlich. Ja. In Perl ist das trivial: tcp-connect, HTTP request absetzen, Daten senden bzw empfangen (und Transferrate anzeigen). Fertig. > Klar, schafft man mit JavaScript und einem eigenen direkt > kontrollierbaren HTTP-Stack unter node.js auch, die Sprache an sich > schränkt dich da nicht ein. node.js laeuft doch auf dem Server? Das brauch ich nicht, die Serverseite habe ich bereits implementiert. Ich will nun nur noch wissen, wie es auf Clientseite in Javascript geht. > Aber ich hatte verstanden, dass du was für den Browser willst, und da > macht der HTTP-Stack in erster Linie, was er will. Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)? Alles neu zu implementieren mit websockets ist mir zu aufwaendig. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher@tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
[toc] | [prev] | [next] | [standalone]
| From | Ralph Aichinger <ra@pi.h5.or.at> |
|---|---|
| Date | 2019-06-05 15:07 +0200 |
| Message-ID | <qd8epn$a9i$1@pi.h5.or.at> |
| In reply to | #5085 |
Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
> Der typische DAU kann aber nur seinen Webbrowser bedienen. Dem kann man
> kein CLI tool geben.
Eventuell ist es einfacher ein ookla.com-Partner zu werden oder das
Ding zu lizensieren (nein, keine Ahnung wie kompliziert/teuer/problematisch
das ist)? Das ist endbenutzertauglich.
/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2019-06-05 18:09 +0200 |
| Message-ID | <qd90hd.4qk.1@stefan.msgid.phost.de> |
| In reply to | #5085 |
Am 05.06.2019 um 08:30 schrieb Ulli Horlacher:
> Stefan Reuther <stefan.news@arcor.de> wrote:
>> Am 03.06.2019 um 22:31 schrieb Ulli Horlacher:
>>> root@fex01:~# tcpbm flupp.belwue.de
>>> sent: 19752 MB in 10 s = 1975 MB/s
>>> received: 23124 MB in 10 s = 2312 MB/s
>>>
>>> Das sind HTTP GET und POST.
>>> Nix websocket.
>>>
>>> Aber halt Perl und nicht Javascript.
>>
>> Perl mit einem eigenen direkt kontrollierbaren HTTP-Stack vermutlich.
>
> Ja.
> In Perl ist das trivial:
> tcp-connect, HTTP request absetzen, Daten senden bzw empfangen (und
> Transferrate anzeigen). Fertig.
>
>> Klar, schafft man mit JavaScript und einem eigenen direkt
>> kontrollierbaren HTTP-Stack unter node.js auch, die Sprache an sich
>> schränkt dich da nicht ein.
>
> node.js laeuft doch auf dem Server? Das brauch ich nicht, die Serverseite
> habe ich bereits implementiert. Ich will nun nur noch wissen, wie es auf
> Clientseite in Javascript geht.
Genauso, wie du eine Perl-Umgebung auf dem Client installieren kannst,
kannst du natürlich eine node.js-Umgebung auf dem Client installieren.
Aber die node.js-Umgebung bietet dir halt nicht die gleichen APIs wie
der Browser.
>> Aber ich hatte verstanden, dass du was für den Browser willst, und da
>> macht der HTTP-Stack in erster Linie, was er will.
>
> Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)?
Es geht mit JavaScript *im Browser* halt nur mit Einschränkungen, weil
der sich selbst überlegt, wie er dein XMLHTTPRequest auf HTTP abbildet.
Wenn's nur um ein Schätzeisen für den User geht, kann man mit den
Einschränkungen dann auch sicher leben.
Dann kannst du mit 64k-Blöcken arbeiten und schauen, wie nah du an der
Realität landest. Eventuell nutze noch etwas Parallelität, z.B. immer 10
Blöcke aktiv, der Browser sortiert das dann schon irgendwie, so dass
bereits direkt nach dem Empfang eines Pakets klar ist, wie es
weitergeht, und nicht erst in die JavaScript-Engine, GUI usw.
reingerufen werden muss.
Eventuell brauchst du dann auch kein POST sondern kommst mit GET hin
("ist ja nur ein Schätzeisen"). Eventuell kommst du mit Megabyte-Blöcken
genauere Ergebnisse wie mit 64k.
Vielleicht kannst du dann auch bestimmte Einschränkungen bzgl. der
Browser treffen, die ein allgemeiner Dienstanbieter nicht kann. Und sei
es sowas wie "mit Browser $XYZ sind die Ergebnisse am nähesten an der
Realität".
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| Date | 2019-06-05 20:25 +0000 |
| Message-ID | <qd98f2$ig9$1@news2.informatik.uni-stuttgart.de> |
| In reply to | #5085 |
Stefan Ram <ram@zedat.fu-berlin.de> wrote: > Ulli Horlacher <framstag@rus.uni-stuttgart.de> writes: > >Der typische DAU kann aber nur seinen Webbrowser bedienen. Dem kann man > >kein CLI tool geben. > > Neben Web-Browser und Kommandozeilenprogramm gibt es ja auch > noch GUI-Programme. Sie lassen sich auch in Perl schreiben > (wxPerl, Perl-Tk, Perl/Qt, gtk2-Perl, ...). Für Endanwender > bräucht man noch ein Installationsprogramm (PDK deployment > tools?). Wir haben keine Windows-Programmierer. Ausserdem muesste man dann auf Windoows auch noch Perl installieren. Nein, das ist nicht machbar. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher@tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
[toc] | [prev] | [next] | [standalone]
| From | Claus Reibenstein <4spamersonly@kabelmail.de> |
|---|---|
| Date | 2019-06-06 09:49 +0200 |
| Message-ID | <glrurkFee6oU2@mid.individual.net> |
| In reply to | #5089 |
Ulli Horlacher schrieb am 05.06.2019 um 22:25: > Ausserdem muesste man dann auf Windoows auch noch Perl installieren. > Nein, das ist nicht machbar. <http://www.perl.org/get.html> Gruß Claus
[toc] | [prev] | [next] | [standalone]
| From | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| Date | 2019-06-06 08:47 +0000 |
| Message-ID | <qdajul$u0a$1@news2.informatik.uni-stuttgart.de> |
| In reply to | #5090 |
Claus Reibenstein <4spamersonly@kabelmail.de> wrote: > Ulli Horlacher schrieb am 05.06.2019 um 22:25: > > > Ausserdem muesste man dann auf Windoows auch noch Perl installieren. > > Nein, das ist nicht machbar. > > <http://www.perl.org/get.html> ICH kann das, aber nicht meine User, die sind damit VOELLIG ueberfordert. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher@tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2019-06-08 14:53 +0200 |
| Message-ID | <gm1pe8FmhbfU2@mid.individual.net> |
| In reply to | #5089 |
Ulli Horlacher: > Stefan Ram <ram@zedat.fu-berlin.de> wrote: >> Ulli Horlacher <framstag@rus.uni-stuttgart.de> writes: >>> Der typische DAU kann aber nur seinen Webbrowser bedienen. Dem kann man >>> kein CLI tool geben. >> >> Neben Web-Browser und Kommandozeilenprogramm gibt es ja auch >> noch GUI-Programme. Sie lassen sich auch in Perl schreiben >> (wxPerl, Perl-Tk, Perl/Qt, gtk2-Perl, ...). Für Endanwender >> bräucht man noch ein Installationsprogramm (PDK deployment >> tools?). > > Wir haben keine Windows-Programmierer. Was hat das mit Windows zu tun? wxPerl oder Perl-TK läuft plattformübergreifend. > Ausserdem muesste man dann auf Windoows auch noch Perl installieren. > Nein, das ist nicht machbar. Und für F*EX braucht man kein Perl auf Windows? BTW: Nextcloud hat auch mit mehreren GB oder TB kein Problem, solange der Server entsprechend konfiguriert ist. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| Date | 2019-06-08 19:31 +0000 |
| Message-ID | <qdh2eu$jv1$2@news2.informatik.uni-stuttgart.de> |
| In reply to | #5093 |
Arno Welzel <usenet@arnowelzel.de> wrote: > Ulli Horlacher: > > > Stefan Ram <ram@zedat.fu-berlin.de> wrote: > >> Ulli Horlacher <framstag@rus.uni-stuttgart.de> writes: > >>> Der typische DAU kann aber nur seinen Webbrowser bedienen. Dem kann man > >>> kein CLI tool geben. > >> > >> Neben Web-Browser und Kommandozeilenprogramm gibt es ja auch > >> noch GUI-Programme. Sie lassen sich auch in Perl schreiben > >> (wxPerl, Perl-Tk, Perl/Qt, gtk2-Perl, ...). Für Endanwender > >> bräucht man noch ein Installationsprogramm (PDK deployment > >> tools?). > > > > Wir haben keine Windows-Programmierer. > > Was hat das mit Windows zu tun? wxPerl oder Perl-TK läuft > plattformübergreifend. Es gibt keine (funktionierenden) Perl Compiler fuer Windows mehr. > > Ausserdem muesste man dann auf Windoows auch noch Perl installieren. > > Nein, das ist nicht machbar. > > Und für F*EX braucht man kein Perl auf Windows? Nein. Das geht entweder ueber den Webbrowser oder ein standalone Executable. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher@tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2019-06-08 14:50 +0200 |
| Message-ID | <gm1p9jFmhbfU1@mid.individual.net> |
| In reply to | #5085 |
Ulli Horlacher: > Stefan Reuther <stefan.news@arcor.de> wrote: [...] >> Aber ich hatte verstanden, dass du was für den Browser willst, und da >> macht der HTTP-Stack in erster Linie, was er will. > > Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)? Korrekt. Du kannst natürlich statt einmalig 1 GB auch 100x10 MB nacheinander via XHR abschicken und jeweils messen und dann als Näherung ausreichnen, wie lange es wohl dauern würde, wenn man 1 GB am Stück hat. Aber mit "genau" hat das nichts mehr zu tun, da dann auch 100x der Overhead für Verbindungsaufbau etc. dazukommt. > Alles neu zu implementieren mit websockets ist mir zu aufwaendig. Dann schreibe eine Anleitung, wie die Leute das Perl-Tool nutzen können. Wenn sie in der Lage sind F*EX zu verwenden, werden sie ja auch tcpbm aufrufen können. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| Date | 2019-06-08 19:34 +0000 |
| Message-ID | <qdh2jc$jv1$3@news2.informatik.uni-stuttgart.de> |
| In reply to | #5092 |
Arno Welzel <usenet@arnowelzel.de> wrote: > Ulli Horlacher: > > > Stefan Reuther <stefan.news@arcor.de> wrote: > [...] > >> Aber ich hatte verstanden, dass du was für den Browser willst, und da > >> macht der HTTP-Stack in erster Linie, was er will. > > > > Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)? > > Korrekt. Du kannst natürlich statt einmalig 1 GB auch 100x10 MB > nacheinander via XHR abschicken und jeweils messen und dann als Näherung > ausreichnen, wie lange es wohl dauern würde, wenn man 1 GB am Stück hat. > Aber mit "genau" hat das nichts mehr zu tun, da dann auch 100x der > Overhead für Verbindungsaufbau etc. dazukommt. Eben, das ist dann so sinnlos. Ok, dann ist das Projekt gestorben. "Geht halt nicht". > Dann schreibe eine Anleitung, wie die Leute das Perl-Tool nutzen können. > Wenn sie in der Lage sind F*EX zu verwenden, werden sie ja auch tcpbm > aufrufen können. NO WAY. Das sind DAUs. Ausserdem hat tcpbm erst mal nichts mit F*EX zu tun. Da gibts hoechstens eine Anwenderschnittmenge. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher@tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2019-06-09 00:45 +0200 |
| Message-ID | <2063569.iZASKD2KPV@PointedEars.de> |
| In reply to | #5095 |
Ulli Horlacher wrote: > Arno Welzel <usenet@arnowelzel.de> wrote: >> Ulli Horlacher: >> > Stefan Reuther <stefan.news@arcor.de> wrote: >> [...] >> >> Aber ich hatte verstanden, dass du was für den Browser willst, und da >> >> macht der HTTP-Stack in erster Linie, was er will. >> > >> > Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)? Es gibt immer noch kein “Javascript”. >> Korrekt. Dass es mit clientseitigem Scripting geht, beweist speedtest.net. >> Du kannst natürlich statt einmalig 1 GB auch 100x10 MB nacheinander via >> XHR abschicken und jeweils messen und dann als Näherung ausreichnen, wie >> lange es wohl dauern würde, wenn man 1 GB am Stück hat. Aber mit "genau" >> hat das nichts mehr zu tun, da dann auch 100x der Overhead für >> Verbindungsaufbau etc. dazukommt. Schon weil seit HTTP/1.1 “persistent connections” der Default sind, ist das schlicht Unfug. > Eben, das ist dann so sinnlos. > Ok, dann ist das Projekt gestorben. "Geht halt nicht". Glaub nicht gleich alles, was Du liest. -- PointedEars FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix> <https://github.com/PointedEars> | <http://PointedEars.de/wsvn/> Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2019-06-10 17:29 +0200 |
| Message-ID | <gm7ba8Fsm4oU3@mid.individual.net> |
| In reply to | #5096 |
Thomas 'PointedEars' Lahn: > Ulli Horlacher wrote: > >> Arno Welzel <usenet@arnowelzel.de> wrote: >>> Ulli Horlacher: >>>> Stefan Reuther <stefan.news@arcor.de> wrote: >>> [...] >>>>> Aber ich hatte verstanden, dass du was für den Browser willst, und da >>>>> macht der HTTP-Stack in erster Linie, was er will. >>>> >>>> Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)? > > Es gibt immer noch kein “Javascript”. > >>> Korrekt. > > Dass es mit clientseitigem Scripting geht, beweist speedtest.net. Nein, tut es nicht. speedtest.net nutzt Websockets und entsprechende Serverdienst auf der Gegenseite. >>> Du kannst natürlich statt einmalig 1 GB auch 100x10 MB nacheinander via >>> XHR abschicken und jeweils messen und dann als Näherung ausreichnen, wie >>> lange es wohl dauern würde, wenn man 1 GB am Stück hat. Aber mit "genau" >>> hat das nichts mehr zu tun, da dann auch 100x der Overhead für >>> Verbindungsaufbau etc. dazukommt. > > Schon weil seit HTTP/1.1 “persistent connections” der Default sind, ist das > schlicht Unfug. Dann zeige ein Beispiel, wie man das in JavaScript nutzen kann. Die reine Feststellung, dass es etwas gibt, hilft hier exakt gar nicht. >> Eben, das ist dann so sinnlos. >> Ok, dann ist das Projekt gestorben. "Geht halt nicht". > > Glaub nicht gleich alles, was Du liest. Da Herr Lahn auch nichts besseres vorschlägt - glaube es ruhig. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2019-06-09 11:10 +0200 |
| Message-ID | <qdipfo.1rg.1@stefan.msgid.phost.de> |
| In reply to | #5095 |
Am 08.06.2019 um 21:34 schrieb Ulli Horlacher: > Arno Welzel <usenet@arnowelzel.de> wrote: >> Ulli Horlacher: >>> Stefan Reuther <stefan.news@arcor.de> wrote: >>>> Aber ich hatte verstanden, dass du was für den Browser willst, und da >>>> macht der HTTP-Stack in erster Linie, was er will. >>> >>> Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)? >> >> Korrekt. Du kannst natürlich statt einmalig 1 GB auch 100x10 MB >> nacheinander via XHR abschicken und jeweils messen und dann als Näherung >> ausreichnen, wie lange es wohl dauern würde, wenn man 1 GB am Stück hat. >> Aber mit "genau" hat das nichts mehr zu tun, da dann auch 100x der >> Overhead für Verbindungsaufbau etc. dazukommt. > > Eben, das ist dann so sinnlos. > 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 je nachdem, wieviel Logik, Zeit und Datenvolumen du investierst, um so genauer wird die Messung. Websockets dürften am nähesten kommen. Multiple parallele große XHR für POST und GET für mehrere Sekunden im Kreis senden am zweitbesten. Dazu wäre aber noch zu sagen, dass die Browser-APIs zur Zeitmessung inzwischen künstlich in der Genauigkeit beschnitten sind, um Timingangriffen (Meltdown, Spectre) zu begegnen. *Ein* Paket senden und aus der in µs gemessenen RTT Schlüsse zu ziehen klappt also sowieso nicht. >> Dann schreibe eine Anleitung, wie die Leute das Perl-Tool nutzen können. >> Wenn sie in der Lage sind F*EX zu verwenden, werden sie ja auch tcpbm >> aufrufen können. > > NO WAY. Das sind DAUs. > Ausserdem hat tcpbm erst mal nichts mit F*EX zu tun. Da gibts hoechstens > eine Anwenderschnittmenge. Naja, sonderlich engagiert kommst du jetzt in diesem Thread aber auch nicht rüber. 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. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| Date | 2019-06-09 12:06 +0000 |
| Message-ID | <qdisp1$383$1@news2.informatik.uni-stuttgart.de> |
| In reply to | #5097 |
Stefan Reuther <stefan.news@arcor.de> 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. tcpbm macht genauen einen HTTP connect. > Dazu wäre aber noch zu sagen, dass die Browser-APIs zur Zeitmessung > inzwischen künstlich in der Genauigkeit beschnitten sind, um > Timingangriffen (Meltdown, Spectre) zu begegnen. *Ein* Paket senden und > aus der in µs gemessenen RTT Schlüsse zu ziehen klappt also sowieso nicht. Deshalb sendet tcpbm default 10 s lang. > > Ausserdem hat tcpbm erst mal nichts mit F*EX zu tun. Da gibts hoechstens > > eine Anwenderschnittmenge. > > 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! -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher@tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2019-06-10 11:16 +0200 |
| Message-ID | <qdle64.4rs.1@stefan.msgid.phost.de> |
| In reply to | #5098 |
Am 09.06.2019 um 14:06 schrieb Ulli Horlacher: > Stefan Reuther <stefan.news@arcor.de> 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. Fehlkonfigurationen ausgenommen wird kein Browser der letzten 20 Jahre wirklich für jeden Request eine neue Verbindung aufbauen. Browser werden Limits haben, wieviele Verbindungen parallel laufen oder wieviele Requests maximal über eine Verbindung gesendet werden, bevor sie geschlossen wird. Aber Connection-Recycling machen sie. Parallelität sorgt dafür, dass nach dem Ende einer Übertragung bereits ein neuer Request bereitsteht, was den Browser vielleicht motiviert, die Verbindung offen zu halten. Und wenn er stattdessen eine neue Verbindung aufbaut, geht der Aufbau-Overhead im Warten auf die Daten des Parallelrequests unter. >>> Ausserdem hat tcpbm erst mal nichts mit F*EX zu tun. Da gibts hoechstens >>> eine Anwenderschnittmenge. >> >> 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. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| Date | 2019-06-10 09:47 +0000 |
| Message-ID | <qdl8uu$mkk$1@news2.informatik.uni-stuttgart.de> |
| In reply to | #5099 |
Stefan Reuther <stefan.news@arcor.de> wrote: > Am 09.06.2019 um 14:06 schrieb Ulli Horlacher: > > Stefan Reuther <stefan.news@arcor.de> 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. > 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. > >> 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. Country UND Western. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher@tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2019-06-10 20:35 +0200 |
| Message-ID | <2489132.mvXUDI8C0e@PointedEars.de> |
| In reply to | #5100 |
Ulli Horlacher wrote: > Jeder HTTP connect dauert vieeeeeeeeeeeeeeeel laenger als das Uebertragen > von Daten. Wie kommst Du auf dies schmale Brett? -- PointedEars FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix> <https://github.com/PointedEars> | <http://PointedEars.de/wsvn/> Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2019-06-11 17:50 +0200 |
| Message-ID | <qdoplg.4bs.1@stefan.msgid.phost.de> |
| In reply to | #5100 |
Am 10.06.2019 um 11:47 schrieb Ulli Horlacher: > Stefan Reuther <stefan.news@arcor.de> wrote: >> Am 09.06.2019 um 14:06 schrieb Ulli Horlacher: >>> Stefan Reuther <stefan.news@arcor.de> 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
[toc] | [prev] | [next] | [standalone]
| From | Ulli Horlacher <framstag@rus.uni-stuttgart.de> |
|---|---|
| Date | 2019-06-11 20:02 +0000 |
| Message-ID | <qdp1ce$ljh$1@news2.informatik.uni-stuttgart.de> |
| In reply to | #5113 |
Stefan Reuther <stefan.news@arcor.de> wrote: > >>> 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? Gemessen. > Und insbesondere: gemessen im Kontext eines Browsers? Beides. > 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. Du vergisst den Overhead beim Serverstart. > 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. Meine Server machen ca 5 GB/s Durchsatz. In dem Bereich muesste ich Daten verschicken um den Overhead zu minimieren. Das ist bei langsamer Client-Anbindung (DSL, WLAN, etc) unbrauchbar. > >> 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. Einen Proxy kannst du nicht beeinflussen. Du musst den benutzen, so, wie er ist. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher@tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/
[toc] | [prev] | [next] | [standalone]
| From | Ralph Aichinger <ra@pi.h5.or.at> |
|---|---|
| Date | 2019-06-12 07:45 +0200 |
| Message-ID | <qdq3h1$2j5$1@pi.h5.or.at> |
| In reply to | #5114 |
Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
> Du vergisst den Overhead beim Serverstart.
Läßt man nicht heute einen Pool von Prefork-Servern durchlaufen?
/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | de.comp.lang.javascript
csiph-web