Baie het al gehoor dat Cloud4Y 'n ondernemingswolkverskaffer is. Daarom sal ons nie oor onsself praat nie, maar 'n kort storie deel oor hoe ons probleme gehad het om toegang tot sommige werwe te kry en wat dit veroorsaak het.
Een mooi dag het die bemarkingsafdeling by die ingenieurs gekla dat wanneer daar deur die terminaal in blaaiers gewerk word, sommige werwe lank geneem het om te laai. In die besonder, vk.com is noodsaaklik vir hulle. Ons het die sein ontvang en begin uitvind wat die probleem was.
So, die situasie: Megafon-internetverskaffer, Windows-bediener-bedryfstelsel, Firefox-blaaier. As u VKontakte met gewone Windows 10 oopmaak, sal die webwerf binne 10-100 ms laai. As ons probeer om met Windows Server 2012/16/19 oop te maak, is die vertraging tot 15 sekondes, of selfs meer.
Geneem , en deur hom het hulle begin om moontlike weergawes uit te werk van wat besig was om te gebeur.
Toets hipotese No. 1 - 'n probleem met die terminale bediener.
Nie bevestig nie. Toe die bladsy deur 'n ander bediener op dieselfde netwerk oopgemaak word, het die probleem voortgeduur.
Toets hipotese nr. 2 - die probleem is in die poort.
Nie bevestig nie. Daar is opgemerk dat op plaaslike skootrekenaars alles maklik en vinnig oopmaak. Maar terselfdertyd duur die probleem voort vir terminale (en interne bedieners). Ons het met die ICMP-instellings op die eksterne en interne koppelvlakke gespeel β dit het nie gehelp nie.
Dis op een of ander manier vreemd.
Vanaf 'n plaaslike skootrekenaar vertraag die webwerf nie.
Vanaf die interne Scan masjien (terminaal vir skandering) - vertraag nie.
Maar bemarking is stadig. Wanorde!
Kom ons gaan aan.
Toets hipotese #3 - DNS probleem.
Nie bevestig nie. Ons het die pixel deur openbare DNS (8.8.8.8) bekendgestel - dieselfde storie. Die probleem is duidelik sigbaar die eerste keer dat jy hierdie pixel byvoorbeeld in incognitomodus trek.
Daar is 'n vermoede dat die probleem baie van die blaaier afhang. In FF vries die pixel altyd, in chroom by die eerste aanmelding. Bemarking sit heeltyd vas op alle blaaiers.
Toets hipotese #4 - Iets met die OS-sjabloon.
Nie bevestig nie. Ons het 'n skoon Windows Server 2016 ontplooi en die toets vanaf die .0-netwerk uitgevoer. Ons het 'n probleem. Ons het na die .200-netwerk oorgeplaas, die probleem het voortgeduur. Dit wil sΓͺ, die netwerkhek is .0. niks daarmee te doen nie. Skootrekenaars van hierdie netwerk het egter nie hierdie probleem nie. Dit wil sΓͺ, die netwerkhek is .200. ook niks daarmee te doen nie.
Dit wil sΓͺ, dit gaan nie oor die OS-sjabloon nie. Die virtuele masjien vertraag terwyl die pixel laai. Maar as jy 'n VPN (aparte netwerkkaart) daarop installeer en verkeer daardeur stuur, dan werk alles baie vinnig (soos dit moet wees). Ons sien dat daar twee opsies is wat 'n probleem kan veroorsaak: 'n poort in die kantoor of 'n internetoperateur in die kantoor.
Maar kan Megafon spesifiek toegang tot die VKontakte-pixel afsny? Nee, dis een of ander nonsens. Kom ons probeer nog bietjie grawe.
Toets hipotese No. 5 - VMware Tools is die skuld vir alles.
Nie bevestig nie. Geen skadelike effekte word waargeneem nie. Ons het probeer om die kaartinstellings te verander, maar dit het ook nie gewerk nie. TTL verander - geen effek nie. Wel, dit is oor die algemeen nie duidelik wat die verskil is tussen Windows 10 en Windows Server nie. Maar daar is 'n verskil. Soos die storie met die gopher.
Ons het al 'n geruime tyd met die probleem te doen. Ons het natuurlik soortgelyke situasies gegoogle, maar niks gevind nie. Ons het dus opgetree sonder om te vra en alle moontlike weergawes uit te werk. Ons het toetse vanaf 'n Windows 2016-skootrekenaar gedoen om seker te maak dat virtualisering ensovoorts nie die skuld is vir die verlangsaming wanneer die pieksel gelaai word nie. Ons het alle moontlike instellings van die netwerkkaart en IP-stapel verander. Ons het 'n klomp dinge probeer. Maar die probleem het gebly, en bemarking het ingeskop en geΓ«is dat alles reggemaak word.
Na 'n ruk het ons uiteindelik gevind waar die hond begrawe is. Dit het alles oor die opsies gegaan
netsh-koppelvlak tcp setglobal ecncapability=gedeaktiveer
Hierdie opsie is by verstek gedeaktiveer op rekenaar Windows-bedryfstelsels en by verstek geaktiveer op bedienerbedryfstelsels. Sodra ons dit op die bedienerkamer deaktiveer, maak alles onmiddellik oop, net soos op die lessenaar. Ons kon hierdie probleem bevestig van die verskaffer wat ons van internet in die kantoor voorsien (Megafon), deur Megafon se mobiele internet (as jy dit vanaf jou foon deel en deur Windows Server koppel), deur Yota, ons het dit in sommige gebiede probeer van Moskou en hierdie probleem was oral teenwoordig. Toe u aan ander operateurs gewerk het, was toegang tot die webwerf onmiddellik.
Dit is so 'n warboel, soos een prominente politieke figuur dit gestel het. In beginsel is die probleem nou opgelos, maar ons stel baie belang: het dit net hier plaasgevind of is dit 'n grootskaalse ramp wat maatskappye van ander stede raak? As hierdie geval nie 'n geΓ―soleerde een is nie, moet Megafon daaraan dink om hierdie probleem op te los. Die opsie ECN (ecncapability) is immers by verstek op bedieners geaktiveer, en dit neem baie tyd om uit te vind waaroor dit gaan.
Hoe om te kontroleer? Ja, net soos ons. Deur die Firefox-blaaier te gebruik, probeer ons enige bladsy op vk.com oopmaak en weer met Ctrl+f5. As daar 'n probleem is, sal daar 'n konstante vertraging wees, as daar geen probleem is nie, sal die webwerf onmiddellik oopmaak.
Wat kan jy nog op die blog lees?
β
β
β
β
β
Teken in op ons -kanaal, om nie die volgende artikel te mis nie! Ons skryf nie meer as twee keer per week nie en slegs vir besigheid.
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Ervaar jy 'n vertraging in die laai deur Windows Server?
-
4,8%Ja, dit neem lank om te laai2
-
50,0%Nee, alles vlieg21
-
45,2%Die probleem is nie in die instellings nie, maar in die bemarkers19
42 gebruikers het gestem. 35 gebruikers het buite stemming gebly.
Bron: will.com