Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build timeouts on ReadTheDocs #2209

Closed
shoyer opened this issue Jun 1, 2018 · 4 comments
Closed

Build timeouts on ReadTheDocs #2209

shoyer opened this issue Jun 1, 2018 · 4 comments

Comments

@shoyer
Copy link
Member

shoyer commented Jun 1, 2018

A significant fraction of our doc builds have started running up against ReadTheDocs's 900 second timeout for builds:
screen shot 2018-06-01 at 8 49 41 am

Investigating a few of these, it seems that the main culprit is installing/downloading conda packages in the conda env create and conda install steps. In some cases, these take over 700 seconds combined, leaving little time for Sphinx, which on its own takes only a couple minutes (but RTD runs it three times for some reason).

@shoyer
Copy link
Member Author

shoyer commented Jun 1, 2018

We see the same issue with our builds on Travis-CI.

Here's our latest doc build on Travis:
https://travis-ci.org/pydata/xarray/jobs/386509884

Notice that it took 411 seconds to run conda env create!

I'm not quite exact what the underlying issue is here (e.g., download vs install time), but I'm sure it's somehow related to our large number of dependencies. If download time is the issue, then perhaps caching downloaded conda packages would help, e.g., readthedocs/readthedocs.org#3261

@ocefpaf
Copy link
Contributor

ocefpaf commented Jul 24, 2018

Notice that it took 411 seconds to run conda env create!

If you are using conda-forge bare in mind that our package index is huge and conda is not very smart about it. We are looking into possible solution. Pinging @pelson who have some ideas in mind on how to address this problem.

@pelson
Copy link

pelson commented Jul 25, 2018

Pinging @pelson who have some ideas in mind on how to address this problem.

The ideas relate to the fetching of the index, which will take orders of magnitude less time than the resolve and download stages in conda. They aren't entirely unrelated though, as a smaller index (the proposal) would result in fewer options for the conda solver to have to work through. No matter what we do, caching the binaries will have the same impact, though it is a challenge to cache sensibly without having a really large cache... You may find that caching an environment.yaml actually has more of an impact than caching the binaries themselves (i.e. this means you continue to download the binaries each time, but don't do a conda resolve each time).

@fmaussion
Copy link
Member

Closed via readthedocs/readthedocs.org#4432

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants