Fast på «Resolving Host in Proxy Script»? Sjå på PAC-fila
Ein nettlesar kan venta på DNS medan han avgjer kva proxy han skal bruka, før han opnar sambandet som lastar ned sida.
Statusmeldinga seier «Resolving host in proxy script», men det hjelper lite å byte proxyserver. Det er eit nyttig spor: nettlesaren avgjer kanskje framleis kvar førespurnaden skal sendast.
Ei PAC-fil kan utføra DNS-avhengige kontrollar. Viss desse kontrollane ventar på ein utilgjengeleg resolver eller gjentek gonger stiller unødvendige spørsmål, kan innlastinga av sida stogga før den valde proxyen får noko.
1. Finn kvar pausen er
For éin råka URL, fastslå om forseinkinga oppstår ved henting av PAC-fila, ved vurderinga av ho eller ved tilkopling til proxyen som vert returnert. Ein tom proxy-tilgangslogg samsvarar med dei to første trinna; han bevisar ikkje at nettlesaren brukte ein direkte rute.
Undersøk deretter kva reglar som treng DNS. Microsoft sine retningslinjer for PAC-ytelse rår til å unngå unødvendig DNS-avhengig arbeid. Ein likskapskontroll av vertsnamn treng ikkje dei same opplysningane som å slå opp vertsnamnet og kontrollera eit subnett.
2. Fjern unødvendig DNS-arbeid
Kjende unntak for vertsnamn kan ofte avgjerast før breie adressebaserte kontrollar. Slå berre opp eit namn når den gjenverande policyen faktisk treng adressa. Ta vare på resultatet i ein lokal variabel viss fleire etterfølgjande vilkår treng same verdi.
Ikkje «reparer» eit tregt skript ved å leggje til ein uvilkårleg DIRECT-retur øvst. Det fjernar rutingsavgjerda saman med forseinkinga.
Maskinspesifikke DNS-løysingar treng bevis. Å slå på fildeling eller skrive om hosts-fila på kvar berbar PC er ein dårleg første reaksjon på eit tregt rutingsskript. Kontroller åtferda til resolveren og vertsnamnet på det råka nettet, særleg etter ei nettverksendring, og endre PAC-en berre der den faktiske avgjerdsvegen krev det.