Ŝtopita ĉe “Resolving Host in Proxy Script”? Rigardu la PAC-dosieron
Retumilo povas atendi DNS dum ĝi decidas kiun prokurilon uzi, antaŭ ol ĝi malfermas la konekton, kiu elŝutas la paĝon.
La statmesaĝo diras “Resolving host in proxy script,” sed ŝanĝi prokurilajn servilojn apenaŭ helpas. Tio estas utila indico: la retumilo eble ankoraŭ decidas, kien sendi la peton.
PAC-dosiero povas plenumi DNS-dependajn kontrolojn. Se tiuj kontroloj atendas neatingeblan solvilon aŭ ripete starigas senbezonajn demandojn, la paĝa ŝarĝado povas halti antaŭ ol la elektita prokurilo ricevos ion ajn.
1. Trovu la paŭzon
Por unu trafita URL, determini ĉu la prokrasto okazas dum la elŝuto de la PAC-dosiero, dum ĝia takso, aŭ dum la konekto al la redonita prokurilo. Malplena alirprotokolo de la prokurilo kongruas kun la du unuaj etapoj; ĝi ne pruvas, ke la retumilo uzis rektan vojon.
Poste kontrolu, kiuj reguloj bezonas DNS. La gvidlinioj de Microsoft pri PAC-agado rekomendas eviti senbezonan laboron dependan de DNS. Kontrolo pri egaleco de gastigantnomo ne bezonas la samajn informojn kiel solvi tiun gastigantnomon kaj kontroli subreton.
2. Forigu senbezonan DNS-laboron
Konataj esceptoj pri gastigantnomoj ofte povas esti deciditaj antaŭ larĝaj adres-bazitaj kontroloj. Solvu nomon nur kiam la cetera politiko efektive bezonas ĝian adreson. Konservu la rezulton en loka variablo se pluraj sekvaj kondiĉoj bezonas la saman valoron.
Ne “ripari” malrapidan skripton aldonante senkondiĉan DIRECT-redonon supre. Tio forigas la enkursigan decidon kune kun la prokrasto.
Maŝin-specifaj DNS-solvoj bezonas pruvojn. Ŝalti dosierkunhavigon aŭ reverki la hosts-dosieron de ĉiu tekkomputilo estas malbona unua reago al malrapida enkursiga skripto. Kontrolu la konduton de la solvilo kaj de la gastigantnomo en la trafita reto, precipe post reta ŝanĝo, kaj ŝanĝu la PAC nur tie, kie ĝia efektiva decida vojo tion postulas.