[Jenkins-infra] Improve website performance from Asia?
R. Tyler Croy
tyler at monkeypox.org
Wed Oct 3 15:20:21 UTC 2018
On Tue, 02 Oct 2018, Olblak wrote:
> I recently discussed with some people about the speed performance for users located across the world, so I had a look to the data we have.
> I put in attachment two screenshots one about the location of people who went on jenkins.io over the last year and a second which shows time it takes to display the jenkins.io from different places.
> It appears that people from Asia experience 5 time slower connections when they go on jenkins websites than North American or Western European and since one third of Jenkins.io visitors come from Asia, I think it could have great impact to improve their experience
> So I am wondering if we should try to find a solution to this?
> And If they are people interested to contribute?
> I don't have an easy and quick solution right now.
> The two main approaches that I have in mind are:
> 1) Use a CDN in front jenkins websites which will be very expensive
> 2) Deploy an additional Kubernetes cluster to host the different websites, from Asia
> Another advantage of having multiple small cluster instead of one bigger one, it becomes easier to upgrade kubernetes cluster without downtime
> If we go with the second approach, it means
> Deploying Static files on one Azure File Storage per application and per region
> Configuring the different Kubernetes cluster with the different file storage
> Configuring an Azure Traffic Manager to redirect people to the best endpoint (Asia or East America)
The second approach seems to me to be reasonable, though it does mean some more
management overhead for us; two k8s is more headache than one :)
The list of applications you suggest I think should be trimmed however:
> Following applications can be "easily" deployed on those new Clusters
> - jenkins.io
Since this is a static app, this is a no brainer
> - accounts.jenkins.io
I'm not sure what benefit this provides since LDAP would presumably still be in
> - javadoc.jenkins.io
> - reports.jenkins.io
> - repo.azure.jenkins.io
This should only ever be referred to from ci.jenkins.io anyways, I'm not sure
what the benefit of federating this cache would be. Perhaps I'm missing
something you're thinking about though.
> - plugins.jenkins.io
I think the website and plugin site are two definite things we should do first,
they're easy wins IMO.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: not available
More information about the Jenkins-infra