[IE] Registerkey Internet versnellen

[Lenzzz]

Hallo,

Een jaar terug ongeveer las ik in een computerblad dat het mogelijk is om downloads (plaatjes, tekst andere bende) sneller te kunnen binnenhalen in je internet explorer.

Je moest dan een aantal register keys wijzigen.
Voorbeeld.
Normaal als je een website bezoekt dan worden er ongeveer 4 plaatjes per seconden binnen gehaald.
In het register is het mogelijk om van die 4, 16 of 32 te maken.
Je haalt op die manier je plaatjes per seconden sneller binnen.

Ik heb dit zelf ook toegepast en het werkte ook, alleen ja, je formatteert je systeem wel is en dan ben je het weer kwijt.

Heb het hele internet doorgezocht alleen kan het niet vinden. Ook dat blad heb ik niet meer en aan een softwareprogramma zoals download of internet accelerator begin ik niet aan.

Ik hoop dat jullie misschien weten wat deze register instelling kunnen zijn?

[Verwijderd]

Deze bedoel je ?

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPerServer"=dword:00000006
"MaxConnectionsPer1_0Server"=dword:00000006

[ Voor 8% gewijzigd door Verwijderd op 24-06-2006 18:59 ]

[Lenzzz]

Ja en nee, als het goed is heb je er ook een key bij zitten waar je een getal kan instellen.

Kan hier ook wel bij, maar weet niet zeker of het deze is.

Maar in ieder geval bedankt!

Kijk ik heb nog even verder gekeken maar het klopt ,

Ik heb het toegepast en het werkt ! PERFECT
hartelijk dank!

[ Voor 25% gewijzigd door Lenzzz op 24-06-2006 20:51 . Reden: Oplossing ]

[Erw]

Ik kan het niet vinden hoor, in mn Xp Home reg.?

[Z-Dragon]

Dan moet je de keys nog aanmaken.

[asing]

Je kan natuurlijk ook *kuch* Opera 9 installeren. Hier kun je precies instellen hoeveel connecties (en zelfs per server) wordt gebruikt. Opera staat standaard al op 8 per server en 20 in totaal. Hoef je dus nooit meer een registry key op te zoeken.

[elevator]

Dit is meer iets voor Client Software Algemeen aangezien het oevr Internet Explorer gaat. Verder wil ik er even op wijzen dat met deze wijziging je de internet protocollen breekt en je het dus gewoon beter niet kan doen

Windows Clients >> Client Software Algemeen

[The__Virus]

asing schreef op zondag 25 juni 2006 @ 00:19:
Je kan natuurlijk ook *kuch* Opera 9 installeren. Hier kun je precies instellen hoeveel connecties (en zelfs per server) wordt gebruikt. Opera staat standaard al op 8 per server en 20 in totaal. Hoef je dus nooit meer een registry key op te zoeken.

En voor Firefox fans is er Fasterfox .

[burne]

elevator schreef op zondag 25 juni 2006 @ 00:25:
Verder wil ik er even op wijzen dat met deze wijziging je de internet protocollen breekt en je het dus gewoon beter niet kan doen

Verder werkt dit soort gein alleen als je de enige bent die het gebruikt. Als iedereen het doet is alles weer net zo traag als eerst.

[eamelink]

elevator schreef op zondag 25 juni 2006 @ 00:25:
Dit is meer iets voor Client Software Algemeen aangezien het oevr Internet Explorer gaat. Verder wil ik er even op wijzen dat met deze wijziging je de internet protocollen breekt en je het dus gewoon beter niet kan doen

Windows Clients >> Client Software Algemeen

Welke internetprotocollen breek je? Is er ergens het aantal concurrent connecties voorgeschreven?

Burne schreef op zondag 25 juni 2006 @ 21:52:
Verder werkt dit soort gein alleen als je de enige bent die het gebruikt. Als iedereen het doet is alles weer net zo traag als eerst.

Neuh, de vertraging die dit oplost is een vertraging die komt door de eigen browser; die maakt niet optimaal gebruik van de moderne dikke internetpijp die aan vrijwel elke computer hangt. Er wordt gewoon een soort semi-serieel plaatjes binnengehaald terwijl dat gemakkelijk parallel kan

[chem]

eamelink schreef op zondag 25 juni 2006 @ 21:56:
[...]

Welke internetprotocollen breek je? Is er ergens het aantal concurrent connecties voorgeschreven?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

[burne]

eamelink schreef op zondag 25 juni 2006 @ 21:56:
Neuh, de vertraging die dit oplost is een vertraging die komt door de eigen browser; die maakt niet optimaal gebruik van de moderne dikke internetpijp die aan vrijwel elke computer hangt.

Da's onzin. Je schreeuwt harder, en dus krijg je meer aandacht. Dat gaat ten koste van anderen. Die gaan ook harder schreeuwen. Over een paar maanden gebruikt iedereen 16 connects en zitten we weer allemaal even lang te wachten. Alleen de mensen die zich aan de specs houden zijn het haasje. Die wachten nog langer. De rest stelt zich asociaal op, zonder dat ze er iets mee opschieten.

Het is een heel hollandse oplossing, dat wel.

[chem]

Burne schreef op zondag 25 juni 2006 @ 22:53:
[...]

Da's onzin. Je schreeuwt harder, en dus krijg je meer aandacht. Dat gaat ten koste van anderen. Die gaan ook harder schreeuwen. Over een paar maanden gebruikt iedereen 16 connects en zitten we weer allemaal even lang te wachten. Alleen de mensen die zich aan de specs houden zijn het haasje. Die wachten nog langer. De rest stelt zich asociaal op, zonder dat ze er iets mee opschieten.

Het is een heel hollandse oplossing, dat wel.

Server-beheerders kunnen ook een max-connect opgeven per client. Al dan niet via een mod_*

Een betere oplossing is keep-alive en/of pipelining.

[eamelink]

chem schreef op zondag 25 juni 2006 @ 22:05:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

Mjah, max 2 persistent connections?

Burne schreef op zondag 25 juni 2006 @ 22:53:
Da's onzin. Je schreeuwt harder, en dus krijg je meer aandacht. Dat gaat ten koste van anderen. Die gaan ook harder schreeuwen. Over een paar maanden gebruikt iedereen 16 connects en zitten we weer allemaal even lang te wachten. Alleen de mensen die zich aan de specs houden zijn het haasje. Die wachten nog langer. De rest stelt zich asociaal op, zonder dat ze er iets mee opschieten.

Komop, laten we het een beetje technisch houden, en niet in Jip & Janneke taal

Waar jij op doelt, is het openen van meerdere verbindingen naar een saturated server, waar iedere client 1/Nde deel van de pijp krijgt, waar N het aantal users is. Als jij dan vijf connecties opentrekt, dan krijg jij vijf keer zoveel als gemiddeld, en als iedereen vijf connecties opentrekt, krijgt iedereen weer z'n normale portie (minus de extra overhead).

Een gemiddelde webserver zit lang niet aan zijn maximum qua transfer, dus dan is dit niet het geval .

Hier komt de vertraging doordat er een request wordt gedaan, er wordt een 'okay' teruggestuurd, plus een plaatje erachteraan. Als dit plaatje binnen is, dan wordt het volgende plaatje binnengehaald. Als je een grote roundtrip tijd hebt, dan is dit inherent traag, omdat pas begonnen wordt met het sturen van het plaatje als de request binnen is, en de request pas wordt gestuurd als het vorige plaatje binnen is .

Als je echter meer requests tegelijkertijd doet, dan worden er ook meer plaatjes tegelijk verzonden, en heb je in totaal minder roundtrips nodig

Vroegah moest je echter niet te veel connecties doen, omdat je wel leuk 16 plaatjes tegelijkertijd kan binnen proberen te trekken, maar als je pijpje te dun is, dan haal je dat niet op tijd, en krijg je timeouts, waardoor je alleen maar verder van huis bent

Tegenwoordig heeft bijna iedereen wel een lekker dikke pijp waardoor timeouts toch bijna niet meer voorkomen, en zijn de default browserinstelling vaak erg conservatief, waardoor je performance verliest

Het is een heel hollandse oplossing, dat wel.

Pfff, volgens mij ben jij gewoon zo'n sneaky newsgroupleecher waar het probleem wel opspeelt zoals jij het beschrijft

[chem]

eamelink schreef op zondag 25 juni 2006 @ 23:08:
[...]


Mjah, max 2 persistent connections?

de regel is max 2 persistent connections en max 4 'normale' threads/connections.

Het is volgens de RFC default 2/4 en door de eindgebruiker aanpasbaar in de user agent. Desalniettemin is iedereen (alle browser bouwers) het er over eens dat dergelijke functionaliteit niet aan jan-alleman moet worden mogelijk gemaakt, omdat je anders mensen met een 56kb modem krijgt die 32 threads aanvragen "omdat het kan".

Ook een 1-2 mbit lijn met bv 32 of 64 threads kan een server veel te veel (apache) childs doen opslurpen, waardoor je toch een probleem krijgt mbt bereikbaarheid.

[eamelink]

chem schreef op zondag 25 juni 2006 @ 23:14:
de regel is max 2 persistent connections en max 4 'normale' threads/connections.

Dat vind ik niet zo snel terug, maar dat zal dan wel zo zijn

Overigens is de Firefox default 8 connections per server.

Dan lijkt het mij tijd voor een nieuwe RFC

Het is volgens de RFC default 2/4 en door de eindgebruiker aanpasbaar in de user agent. Desalniettemin is iedereen (alle browser bouwers) het er over eens dat dergelijke functionaliteit niet aan jan-alleman moet worden mogelijk gemaakt, omdat je anders mensen met een 56kb modem krijgt die 32 threads aanvragen "omdat het kan".

Nou, dan lijkt het aanpassen in de registry door een tweaker mij geen probleem

Ook een 1-2 mbit lijn met bv 32 of 64 threads kan een server veel te veel (apache) childs doen opslurpen, waardoor je toch een probleem krijgt mbt bereikbaarheid.

Mjah, 64 wordt wellicht wat dosserig, maar zo'n 20 stuks lijkt me zeker niet teveel gevraagd. Als dat nodig is om het maximale uit je internetverbinding te maken, dan lijkt me dat niet onredelijk . Verder lijkt het me qua het aantal child processen dat er spawnt voornamelijk een zaak voor de serversoftware om dat in de hand te houden (binnen het redelijke uiteraard, 10000 connecties maken naar één server is niet zo netjes )

[burne]

eamelink schreef op zondag 25 juni 2006 @ 23:08:
Komop, laten we het een beetje technisch houden, en niet in Jip & Janneke taal

Dat voldoet anders prima.

Hier komt de vertraging doordat er een request wordt gedaan, er wordt een 'okay' teruggestuurd, plus een plaatje erachteraan. Als dit plaatje binnen is, dan wordt het volgende plaatje binnengehaald. Als je een grote roundtrip tijd hebt, dan is dit inherent traag, omdat pas begonnen wordt met het sturen van het plaatje als de request binnen is, en de request pas wordt gestuurd als het vorige plaatje binnen is .

Ik ruik een drogargument. In een persistent connection heb je geen latency voor het opbouwen van een connect na de eerste keer, en je mag tientallen requests achter elkaar doen, die dan in volgorde 1 voor 1 uit de pijp komen. Dat was het idee van pipelining. Daar gaat latency dus niet op. Met het aanzetten van pipelining zijn jij en de webserver veel beter af. Waarom leg je mensen niet uit hoe pipelining werkt en hoe ze het aanzetten? Dat helpt echt, is niet asociaal en is wel te onderbouwen met een technisch verhaal. Hoef je je ook niet in bochten te wringen om de asociale oplossing recht te praten.

Pfff, volgens mij ben jij gewoon zo'n sneaky newsgroupleecher waar het probleem wel opspeelt zoals jij het beschrijft

Wat mij betreft wordt usenet met ingang van vandaag text only. Gewoon geen binaries. Ik gebruik overigens al bijna tien jaar een server die enkel tekstgroepen voert. Gratis, doet het altijd, nooit traag en een retentie van een half jaar of meer op een enkel 250Gbyte schijfje.

[Verwijderd]

Burne schreef op zondag 25 juni 2006 @ 22:53:
[...]

Da's onzin. Je schreeuwt harder, en dus krijg je meer aandacht. Dat gaat ten koste van anderen. Die gaan ook harder schreeuwen. Over een paar maanden gebruikt iedereen 16 connects en zitten we weer allemaal even lang te wachten. Alleen de mensen die zich aan de specs houden zijn het haasje. Die wachten nog langer. De rest stelt zich asociaal op, zonder dat ze er iets mee opschieten.

Het is een heel hollandse oplossing, dat wel.

Amen ja