Oferiți fiecărui lucrător HtmlUnit un proxy stabil

job A → WebClient A → proxy A → destination
job B → WebClient B → proxy B → destination

Atribuiți un HtmlUnit WebClient configurat fiecărei identități de navigare simultane. WebClientOptions-ul său deține ProxyConfig; tratați ruta ca fixă cât timp sarcina rulează. O coadă de sarcini partajată nu necesită un browser mutabil partajat. Pentru verificările permise ale paginilor publice cu HTTP ProxyConfig, alegeți puncte finale candidate din lista de proxy HTTP înainte de a le atribui lucrătorilor.

Păstrați pagina, încărcările ulterioare și starea sesiunii la acel client. Schimbarea opțiunilor de proxy nu poate transplanta conexiunile deja stabilite. Clienții separați creează și stare de browser separată, așa că planificați orice autentificare partajată dorită în loc să presupuneți că doar rutarea determină identitatea. Autentificarea proxy folosește interfața versiunii HtmlUnit instalate și rămâne separată de autentificarea pe site.

Definiți finalizarea înainte de a returna un browser într-un pool. Răspunsul de nivel superior poate sosi în timp ce scripturile sau cererile din fundal continuă. Finalizați sau anulați acea lucrare, curățați starea pe care următoarea identitate nu trebuie să o moștenească și retrageți clientul dacă această limită nu poate fi stabilită în mod fiabil.

Limitați numărul de clienți activi și închideți WebClients finalizați. Un browser analizează și poate executa scripturi, ceea ce costă mai mult decât un transfer simplu. Pentru o sarcină care are nevoie doar de HTML-ul returnat, un client HTTP mai mic poate susține mai multe cereri simultane în același buget de resurse.