While comparing the speed index for the same URL between public and private instance, we saw there is a 50% deviations. The public instance shows better speed index. There is obvious difference in TTFB because of the latency with private instance. There is no difference in Browser versions. Wanted to know why the public instances has better speed index.
What instances sizes (or VM) are you using for the private instance? Usually differences like that come down to underpowered VM’s (c5.large is recommended as the minimum size if you are on EC2).
Another possibility is if you are using Ubuntu 20.04 which seems to perform a fair bit slower than 18.04 LTS which is what the public agents use.
Otherwise it could be something networking or traffic-shaping related.
Hi Pat, is there a recommendation for server size / configuration on Azure?
Something around the same size as C5.large (particularly the compute side). Basically a 2-CPU VM with at least 4GB of RAM.
Make sure to stay away from burstable instances - you want consistent performance.
Looks like Standard_D2 (or some similar variant) is probably the closest.
Thanks Pat, I have tried to work with the standard F2 (2CPU / 4GB) which I do not believe are burstable and are set up for ‘compute optimized’ , but feel they do not perform as well as the C5 series on AWS.
Would a 4CPU give a better result than a 2 CPU, or is there no real advantage in the extra CPUs?
I am aware that Catchpoint run WPT on Azure, do you know what config size they are set up on as they appear to give lower/faster timings etc?.
Any other config advice for configuring on Azure would also be appreciated.
Yes, Chrome can make use of a fair number of cores these days with background JS parsing and iFrames running in separate processes, etc.
I’ll ping the ops team to see what instance size we’re using for Azure - can’t remember off the top of my head.
What version of Ubuntu were you using?
That would be very useful.
I have been on 18.04 since the start and following your comment above, wont be changing any time soon, unless the upgrade is recommended.
Looks like we’re using Standard_DS3_v2
Much appreciated and thanks for your insight
Thank you Pat for the reply. The reply made us revisit the infrastructure we were trying to setup. We were using Windows Agent and now we moved to Ubuntu 18.04 linux agent and also moved to c5.large. This worked for a day and then stopped working. Logged in to the Agent, and curl calls for getWork to the master seemed working. But there were no request seen in the master logs from the agent. Also unable to see the logs in the agent.
Would there be any such issue reported for the linux agent recently?
Where do we see the agent logs?
If you ssh into the agent with the “ubuntu” user account you can “screen -r” and see the live agent output as it is running.
The production infrastructure all runs on the linux agent on 18.04 and we haven’t seen any issues in any of the clouds recently that match what you are seeing.