Skip to main content

Built-in Queueing System

Browserless includes a simple built-in queueing system that manages browser concurrency and request flow. This system ensures optimal resource utilization while preventing your infrastructure from being overwhelmed by too many simultaneous browser instances.

How the Queueing System Works​

Browserless implements a three-tier system to manage browser requests:

Concurrency Limit​

When you start a browser session, it first checks if you're within your allotted concurrency limit. If you are, the browser starts immediately. This is the fastest path and ensures optimal performance for your requests.

Queueing​

Once you surpass your concurrency limit, new requests are placed in a queue rather than being rejected immediately. This allows your requests to wait for an available slot without losing the work. The system will process queued requests in order as browser slots become available.

Request Rejection​

If your queue becomes full (you've exceeded your allotted queueing slots, which is the same as your concurrency), new requests will be rejected with an appropriate error message. This prevents system overload and ensures that existing requests can complete successfully.

Why Proper Browser Cleanup Matters​

The queueing system relies on browsers being properly closed to free up slots for queued requests. When browsers aren't closed correctly, they continue consuming resources until they hit the default timeout, which can cause unnecessary delays for other requests.

The Problem with Hanging Browsers​

When browsers are left open without proper cleanup:

  • Resource Waste: Each hanging browser continues consuming CPU and memory
  • Queue Delays: Queued requests must wait longer for slots to become available
  • Timeout Issues: Browsers may hit navigation timeouts due to resource constraints
  • Reduced Throughput: Fewer requests can be processed efficiently

Best Practices for Browser Management​

To ensure optimal performance and prevent hanging browsers:

  • Always close browsers when done: Call browser.close() when your task completes
  • Handle errors gracefully: Close browsers even when unhandled errors occur to free up resources
  • Set reasonable timeouts: Configure appropriate timeout values for your use case, as the default timeout may be too high for your needs.
  • Monitor your usage: Keep track of your concurrency and queue limits

Concurrency and worker's health​

Health Check Options​

You can enable health check options in your worker settings to have the system ping your machine and verify its health status before starting a new browser. This helps ensure that browsers only start when your infrastructure has sufficient resources available, preventing timeouts and performance issues.

Managing Concurrency for High Resource Usage​

If you're experiencing large amounts of timeouts when running many requests, you can adjust your max concurrency in your worker settings. This setting puts a limit on how many browsers can run simultaneously per machine.

For high CPU/memory consumption use cases, consider running fewer browsers per machine by reducing your max concurrency setting or instantiating larger machines. This approach provides several benefits:

  • Reduced Resource Contention: Each browser gets more CPU and memory resources
  • Fewer Timeouts: Less competition for system resources means more reliable performance
  • Better Stability: Lower concurrency reduces the chance of system overload
  • Improved Success Rates: Browsers are less likely to fail due to resource constraints

The optimal concurrency setting depends on your specific use case, machine specifications, and the complexity of your browser automation tasks. Start with a conservative setting and adjust based on your performance metrics.