What to Consider Before Purchasing Your Plan?

Every web automation workload is different and we provide various plans in different sizes with different quantities, i.e. number of VM instances to run your workload. In this guide, we will explain the things you need to consider before purchasing your plan.

When do you need multiple instances?

We will provide a high overview of your dedicated environment with the following diagram. In this diagram, a plan with two VM instances depicted. Note that, plan size, thus the size of VM is purposely ignored and discussed later on. 


As depicted above, your VM instances are running behind a publicly available load balancer, and the endpoint URL for the load balancer is given in My Products page. Whenever you connect to endpoint, a VM in the pool is choosen in round robin fashion to launch a headless browser. In the diagram an active connection to VM₁ is depicted, so the active browser is actually running on VM₁.

Every VM on your environment has their own public IP addresses for outgoing connections. When you navigate to target web site URL from the first browser connection you open, headless browser running on VM₁ will fetch the content of target web site through Public IP₁. As long as you keep the browser connection alive, and open new pages towards target web site all cookies and session information are gonna be persisted in the headless browser session, and the connection from headless browser to target website remains active through Public IP₁. The best way to start a fresh session, is to open a new browser connection. This new browser connection will be forward to VM2 and you'll have a new browser session from a different IP address.

The flow described above is very useful if the target web site is using IP based rate limitations. Hence, having multiple instances allows you to have an IP pool inheritenly to run your web automation workload. You can come up with your own strategy to mitigate IP based rate limitations. 

In general for each plan, we have certain bandwith limits per instance, per month. Having multiple instances has direct impact on the total bandwith limit (sum of all outbound traffic) allocated your plan. If you need more bandwith, you need to allocate more instances. 

Choosing the right size for your workload

As a rule of thumb, you need to consider Medium, Large and X-Large plans for your productions workload. Our Small plan is especially designed for development and testing workloads. Apart from the limits dedicated to Small plan, one of the main difference is the underlying VM type we are offerring. This particular VM is able to handle CPU bursts in a special way. On daily basis, a certain amount of CPU credits are allocated for the VM, and when there is a CPU burst the credits are used to handle the load. Whenever all CPU credits consumed, there will be degraded performance, which makes this particular size very efficient for development and testing purposes, for a relatively cheaper price. 

By default, all plans other than the Small one is using accelerated networking, which means that there is no additional network hops and interim virtual switches between the physical network switches and your VM machines. 

When it comes to the productions workloads, there are many factors which can affect the performance of your workload.

Geographic Locations

It's possible that your target website is operating in a particular geographic location based on the hosting configuration. Even if you can access the website globally, getting closer to target web site may considerably increase your performance. By default, Browseasy is operating in West Europe region and all plans are deployed to data centers in this particular region. If you need to have any plan in any other region, please contact us for an Enterprise Plan.

Web Performance of the Target Site

Your web automation performance is directly affected by the web performance of the target site you are working on. Unfortunately, it's a very subjective topic and it's not easy to categorize each web sites based on certain aspects of the web site. However, in general we can say that if the web site

• is resource intensive, i.e. consists of multiple HTML, CSS, JavaScript and media files, having a higher data transfer speed
• is a single page application, i.e. generally relies on the JavaScript performance on the client browser, having more CPU power and RAM

can increase your web automation performance. As a consequence, you need to consider larger Browseasy plans.

Web Automation Design, Frameworks & APIs

Generally, which framework you use for your web automation does not have direct impact on choosing your plan. In the end, any framework and API you use, should rely on Chrome DevTools protocol to communicate with headless browsers. However, your design might have. If your web automation process relies on longer browser session, i.e. you need to interact with the target web site for a longer time, then having more RAM on your VM will be required. Regardless from your browser session time, if you need more concurrent browser session then having more CPUs, and VM instances more important than any other consideration for choosing the right plan.

Please note that, we do not enforce any browser session limits which would affect how you use Browseasy. Instead, all cloud resources with certain limits are reserved for your own use. It's totally up to you, how to consume these resources. You can always optimize your web automation workload on your side, come up with new and efficient ways to utilize these cloud resources. For instance, you can enforce on your side how many browsers you can run concurrently, in which order you execute your processes etc.