Mesazhi i statusit thotë «Resolving host in proxy script», por ndryshimi i serverëve proxy nuk ndryshon shumë. Ky është një tregues i dobishëm: shfletuesi mund të jetë ende duke vendosur ku ta dërgojë kërkesën.

Një skedar PAC mund të kryejë kontrolle që varen nga DNS. Nëse ato kontrolle presin një zgjidhës të paarritshëm ose bëjnë vazhdimisht pyetje të panevojshme, ngarkimi i faqes mund të ndalet përpara se proxy-ja e zgjedhur të marrë ndonjë gjë.

1. Lokalizoni ndalesën

Për një URL të prekur, përcaktoni nëse vonesa ndodh gjatë marrjes së skedarit PAC, gjatë vlerësimit të tij apo gjatë lidhjes me proxy-në e kthyer. Një regjistër aksesi proxy i zbrazët përputhet me dy fazat e para; ai nuk provon që shfletuesi përdori një rrugë të drejtpërdrejtë.

Më pas kontrolloni cilat rregulla kanë nevojë për DNS. Udhëzimet e Microsoft për performancën e PAC rekomandojnë shmangien e punës së panevojshme që varet nga DNS. Një kontroll barazie i emrit të hostit nuk ka nevojë për të njëjtat informacione si zgjidhja e atij emri dhe kontrolli i një nënrrjeti.

2. Hiqni punën e panevojshme me DNS

Përjashtimet e njohura për emrat e hosteve shpesh mund të vendosen përpara kontrolleve të gjera të bazuara në adresa. Zgjidhni një emër vetëm kur politika e mbetur ka vërtet nevojë për adresën e tij. Mbajeni rezultatin në një ndryshore lokale nëse disa kushte pasuese kanë nevojë për të njëjtën vlerë.

Mos e «rregulloni» një skript të ngadaltë duke shtuar një kthim DIRECT pa kushte në krye. Kjo heq vendimin e rrugëtimit bashkë me vonesën.

Zgjidhjet DNS specifike për makinën kërkojnë prova. Aktivizimi i ndarjes së skedarëve ose rishkrimi i skedarit hosts në çdo laptop është një reagim i parë i dobët ndaj një skripti të ngadaltë rrugëtimi. Kontrolloni sjelljen e zgjidhësit dhe të emrit të hostit në rrjetin e prekur, veçanërisht pas një ndryshimi rrjeti, dhe ndryshoni PAC vetëm aty ku e kërkon rruga e tij reale e vendimit.

Artikuj të ngjashëm