This emerged from me looking into how we use browserstack due to #24
I have some proof of concept code (since a while, demoed it on a Fridays call), ~but I have not published it. Will do so later in an unpolished way~ See googlefonts/gftools#246 and #28 .
The idea is to run as many Browserstack jobs as the API let's us do, in order to finish the overall task quicker.
The source of this issue is that simultaneous jobs at Browserstack are limited per API key and the some of us share the same API Key; further, these jobs run pretty long—probably because of provisioning, then booting the several VMs we need.
@m4rc1e had an issue with that maxin out in parallel, roughly: when we do this then some clients not get instant service from the external API. (please correct me if I got this wrong).
I think in the end we'll see the same speed overall when the resources is crowded but very good improvements when it's not.
Further, I'd argue that the serial, one job at a time, approach hides it (longer) when we approach a number of shared API-Key users, that makes the tool unusable.
One general significant improvement of the POC code ~(to be shared)~ is that it, serial or parallel approach, can handle Parallel limit reached errors and HTTP Retry-After response-headers of the Browserstack API correctly. So, even if there's no free slot, the POC code will retry until it is served.
The current implementation will just fail and require the user to re-run the script.
This emerged from me looking into how we use browserstack due to #24
I have some proof of concept code (since a while, demoed it on a Fridays call), ~but I have not published it. Will do so later in an unpolished way~ See googlefonts/gftools#246 and #28 .
The idea is to run as many Browserstack jobs as the API let's us do, in order to finish the overall task quicker.
The source of this issue is that simultaneous jobs at Browserstack are limited per API key and the some of us share the same API Key; further, these jobs run pretty long—probably because of provisioning, then booting the several VMs we need.
@m4rc1e had an issue with that maxin out in parallel, roughly: when we do this then some clients not get instant service from the external API. (please correct me if I got this wrong).
I think in the end we'll see the same speed overall when the resources is crowded but very good improvements when it's not. Further, I'd argue that the serial, one job at a time, approach hides it (longer) when we approach a number of shared API-Key users, that makes the tool unusable.
One general significant improvement of the POC code ~(to be shared)~ is that it, serial or parallel approach, can handle
Parallel limit reachederrors and HTTPRetry-Afterresponse-headers of the Browserstack API correctly. So, even if there's no free slot, the POC code will retry until it is served.The current implementation will just fail and require the user to re-run the script.