Multaj jam aŭdis, ke Cloud4Y estas entreprena nuba provizanto. Sekve, ni ne parolos pri ni mem, sed dividos novelon pri kiel ni havis problemojn aliri iujn retejojn kaj kio kaŭzis tion.
Iun belan tagon, la merkata fako plendis al la inĝenieroj, ke kiam oni laboris per la terminalo en retumiloj, iuj retejoj daŭris longan tempon por ŝargi. Aparte, vk.com estas esenca por ili. Ni ricevis la signalon kaj komencis ekscii, kio estas la problemo.
Do, la situacio: Megafon Interreta provizanto, Vindoza servilo OS, Firefox-retumilo. Se vi malfermas VKontakte kun regula Windows 10, la retejo ŝargiĝos en 10-100 ms. Se ni provas malfermi per Windows Server 2012/16/19, la prokrasto estas ĝis 15 sekundoj, aŭ eĉ pli.
Prenis , kaj per li ili komencis ellabori eblajn versiojn de kio okazis.
Testa hipotezo n-ro 1 - problemo kun la terminala servilo.
Ne konfirmite. Kiam vi provas malfermi la paĝon per alia servilo en la sama reto, la problemo daŭris.
Testa hipotezo n-ro 2 - la problemo estas en la enirejo.
Ne konfirmite. Oni rimarkis, ke ĉe lokaj tekkomputiloj ĉio malfermiĝas facile kaj rapide. Sed samtempe, la problemo daŭras por terminaloj (kaj internaj serviloj). Ni ludis kun la ICMP-agordoj sur la eksteraj kaj internaj interfacoj - ĝi ne helpis.
Estas strange iel.
De loka tekkomputilo la retejo ne malrapidiĝas.
De la interna Scan-maŝino (terminalo por skanado) - ne malrapidiĝas.
Sed merkatado estas malrapida. Malordo!
Ni pluiru.
Testa hipotezo #3 - DNS-problemo.
Ne konfirmite. Ni lanĉis la pikselon per publika DNS (8.8.8.8) - la sama rakonto. La problemo estas klare videbla la unuan fojon kiam vi tiras ĉi tiun pikselon en inkognita reĝimo, ekzemple.
Estas suspekto, ke la problemo dependas multe de la retumilo. En FF la pikselo ĉiam frostas, en chrome ĉe la unua ensaluto. Merkatado estas blokita la tutan tempon en ĉiuj retumiloj.
Testa hipotezo #4 - Io kun la OS-ŝablono.
Ne konfirmite. Ni deplojis puran Windows Server 2016 kaj kuris la teston de la reto .0. Ni havas problemon. Ni translokiĝis al la reto .200, la problemo daŭris. Tio estas, la reto pordego estas .0. nenio rilatas al ĝi. Tamen, tekkomputiloj de ĉi tiu reto ne havas ĉi tiun problemon. Tio estas, la reto pordego estas .200. ankaŭ nenio rilatas al ĝi.
Tio estas, ne temas pri la OS-ŝablono. La virtuala maŝino malrapidiĝas dum ŝarĝo de la pikselo. Sed se vi instalas VPN (aparta retkarto) sur ĝi kaj sendas trafikon tra ĝi, tiam ĉio funkcias tre rapide (kiel ĝi devus esti). Ni vidas, ke estas du ebloj, kiuj povas kaŭzi problemon: enirejo en la oficejo aŭ interreta telefonisto en la oficejo.
Sed ĉu Megafon povas specife malhelpi aliron al la pikselo VKontakte? Ne, ĝi estas ia sensencaĵo. Ni provu fosi iom pli.
Testa hipotezo n-ro 5 - VMware Tools kulpas pri ĉio.
Ne konfirmite. Neniuj malutilaj efikoj estas observitaj. Ni provis ŝanĝi la kartajn agordojn, sed ankaŭ tio ne funkciis. TTL ŝanĝiĝis - neniu efiko. Nu, ĝenerale ne estas klare, kio estas la diferenco inter Windows 10 kaj Windows Server. Sed estas diferenco. Kiel la rakonto kun la gopher.
Ni traktas la problemon dum sufiĉe da tempo. Kompreneble, ni guglis similajn situaciojn, sed trovis nenion. Do ni agis sen instigado, ellaborante ĉiujn eblajn versiojn. Ni faris testadon de tekkomputilo Windows 2016 por certigi, ke virtualigo kaj tiel plu ne kulpas pri la malrapidiĝo dum ŝarĝo de la pikselo. Ni ŝanĝis ĉiujn eblajn agordojn de la retkarto kaj IP-stako. Ni provis amason da aferoj. Sed la problemo restis, kaj merkatado ekis kaj postulis, ke ĉio estu riparita.
Post iom da tempo, ni finfine trovis kie la hundo estis entombigita. Ĉio temis pri la elektoj
netsh-interfaco tcp setglobal ecncapability=malŝaltita
Ĉi tiu opcio estas malebligita defaŭlte en labortablaj Vindozaj operaciumoj kaj ebligita defaŭlte ĉe servilaj operaciumoj. Tuj kiam ni malŝaltas ĝin en la servila ĉambro, ĉio malfermiĝas tuj, same kiel sur la labortablo. Ni povis konfirmi ĉi tiun problemon de la provizanto, kiu havigas al ni Interreton en la oficejo (Megafon), per la movebla Interreto de Megafon (se vi dividas ĝin de via telefono kaj konektiĝas per Windows Server), per Yota, ni provis ĝin en iuj lokoj. de Moskvo kaj ĉi tiu problemo ĉeestis ĉie. Kiam oni laboris pri aliaj funkciigistoj, aliro al la retejo estis tuja.
Ĉi tio estas tia svingo, kiel diris unu elstara politika figuro. Principe, la problemo nun estas solvita, sed ni tre interesiĝas: ĉu ĝi okazis nur ĉi tie aŭ ĉu temas pri grandskala katastrofo, kiu tuŝas kompaniojn el aliaj urboj? Se ĉi tiu kazo ne estas izolita, tiam Megafon devus pensi pri solvi ĉi tiun problemon. Post ĉio, la opcio ECN (ecncapability) estas ebligita en serviloj defaŭlte, kaj necesas multe da tempo por ekscii pri kio temas.
Kiel kontroli? Jes, same kiel ni. Uzante la retumilon Firefox ni provas malfermi ajnan paĝon ĉe vk.com kaj denove uzante ctrl+f5. Se estas problemo, estos konstanta prokrasto, se ne estas problemo, la retejo malfermos tuj.
Kion alian vi povas legi en la blogo?
→
→
→
→
→
Abonu nian -kanalo, por ne maltrafi la sekvan artikolon! Ni skribas ne pli ol dufoje semajne kaj nur pri komerco.
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Ĉu vi spertas prokrastan ŝarĝon per Windows Server?
-
4,8%Jes, necesas longa tempo por ŝargi2
-
50,0%Ne, ĉio flugas21
-
45,2%La problemo ne estas en la agordoj, sed en la merkatistoj19
42 uzantoj voĉdonis. 35 uzantoj sindetenis.
fonto: www.habr.com