NOTE: This information applies for users that have dedicated worker(s) in the capacity-based plan.
To customize your worker settings, log in to your browserless account and click on the the gear icon in the Production Workers tab. There are several settings that you can tweak for your dedicated workers in the popup that appears.
The first two dropdown fields will allow you to pick the chrome/puppeteer version and the global timeout.
By default, you will have the latest version. If a newer version is released, we notify through email and your workers will update automatically the next time your workers are relaunched or restarted. If you want to pin your workers to a specific version, you'll have to select one of these versions from the dropdown.
Once the duration of your session reaches the global timeout, it will be terminated.
If your session runs into an exception and your script doesn't handle it properly, your browser process might not exit properly, causing it to hang and remain open, which leads to consuming unnecessary resources, until it reaches the global timeout. It's always a best practice to implement exception handling in your scripts to avoid this.
The max concurrency and queue can be modified by using the slider.
If you experience many timeouts/errors and rarely see queued sessions, your worker may be running out of resources and your worker is getting gridlocked. You can limit the max concurrency so that sessions don't run out of resources and hit the queue faster.
If you use an external queueing system, you'll want to set your queue to 0, so that we return an error immediately after your concurrency limit has been reached. Bear in mind this feature may not be 100% flawless, due to the async implementation, a request may slip through the cracks if two requests are being received by the server exactly at the same time, so don't panic if a request gets queued even when set to 0.
If this feature is checked on, your worker will check the health of your worker before a session connects, be it an api call or library call; if the load balancer determines your worker(s) can't handle another request, it will throw a 5xx response code. Disabling this will send the requests to your worker blindly, forcing it to take the request independently of the health of the worker.
This feature implements puppeteer-extra-plugin-stealth, which injects user behavior to your page, helping your sessions avoid basic bot detecting techniques.
The following features are experimental, which means they are to be used with caution, since they can have caveats you should consider before enabling them.
This feature will launch browser instances and keep them in a pool of instances in order to cut-down on the boot time. Read more about pre-booting chrome.
The caveat to this feature is that it may impact performance, since there will be more browsers open than necessary at a given point, which take up resources, hence reducing the available resources for your sessions that are actually running. This is recommended trying on large workers only.
This feature allows you to enable special /GET handlers for our APIs. This is handy for cases where you need to directly call our services from a cache-layer like a CDN. Read more information on the /GET APIs.
Please do not call the hosted service from the browser as it will reveal your secret token!
This feature will restart your worker automatically when CPU or Memory usage are above 100% for a period of time (by default 5 minutes). Read more about exiting on health failure