Дайте на всеки HtmlUnit работник стабилен прокси
Задайте прокси опциите на HtmlUnit преди зареждане на страници и не позволявайте на паралелните работници да променят маршрута на един споделен браузърен клиент.
job A → WebClient A → proxy A → destination
job B → WebClient B → proxy B → destinationНазначете конфигуриран HtmlUnit WebClient на всяка едновременна идентичност за сърфиране. Неговият WebClientOptions притежава ProxyConfig; третирайте маршрута като фиксиран, докато задачата работи. Споделена опашка от задачи не изисква един споделен променлив браузър. За разрешени проверки на публични страници с HTTP ProxyConfig изберете кандидат крайни точки от списъка с HTTP прокси, преди да ги назначите на работниците.
Задръжте страницата, последващите зареждания и състоянието на сесията при този клиент. Промяната на прокси опциите не може да премести установени връзки. Отделните клиенти създават и отделно браузърно състояние, затова планирайте всяко планирано споделено влизане, вместо да предполагате, че идентичността се определя само от маршрута. Прокси удостоверяването използва интерфейса на инсталираната версия на HtmlUnit и остава отделно от влизането в уебсайт.
Дефинирайте завършване, преди да върнете браузър в пул. Отговорът на най-горно ниво може да пристигне, докато скриптове или фонови заявки продължават. Завършете или отменете тази работа, изчистете състояние, което следващата идентичност не бива да наследява, и изведете клиента от употреба, ако тази граница не може да се установи надеждно.
Ограничете броя на активните клиенти и затваряйте завършените WebClients. Браузърът анализира и може да изпълнява скриптове, което струва повече от обикновен трансфер. За задача, която се нуждае само от върнат HTML, по-малък HTTP клиент може да поддържа повече едновременни заявки в същия бюджет от ресурси.