2006-09-05 00:06:23 +03:00
|
|
|
|
#include "misc.hh"
|
2006-11-30 19:43:04 +02:00
|
|
|
|
#include "store-api.hh"
|
2008-08-02 15:54:35 +03:00
|
|
|
|
#include "local-store.hh"
|
2012-05-01 02:15:34 +03:00
|
|
|
|
#include "globals.hh"
|
2006-09-05 00:06:23 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
namespace nix {
|
2004-06-18 21:09:32 +03:00
|
|
|
|
|
|
|
|
|
|
2011-09-01 00:11:50 +03:00
|
|
|
|
Derivation derivationFromPath(StoreAPI & store, const Path & drvPath)
|
2004-06-18 21:09:32 +03:00
|
|
|
|
{
|
2005-01-19 13:16:11 +02:00
|
|
|
|
assertStorePath(drvPath);
|
2011-09-01 00:11:50 +03:00
|
|
|
|
store.ensurePath(drvPath);
|
2014-04-08 20:24:29 +03:00
|
|
|
|
return readDerivation(drvPath);
|
2004-06-18 21:09:32 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2012-12-20 19:41:44 +02:00
|
|
|
|
void computeFSClosure(StoreAPI & store, const Path & path,
|
|
|
|
|
PathSet & paths, bool flipDirection, bool includeOutputs, bool includeDerivers)
|
2005-01-19 13:16:11 +02:00
|
|
|
|
{
|
2012-12-20 19:41:44 +02:00
|
|
|
|
if (paths.find(path) != paths.end()) return;
|
|
|
|
|
paths.insert(path);
|
|
|
|
|
|
|
|
|
|
PathSet edges;
|
|
|
|
|
|
|
|
|
|
if (flipDirection) {
|
|
|
|
|
store.queryReferrers(path, edges);
|
|
|
|
|
|
|
|
|
|
if (includeOutputs) {
|
|
|
|
|
PathSet derivers = store.queryValidDerivers(path);
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & i : derivers)
|
|
|
|
|
edges.insert(i);
|
2012-12-20 19:41:44 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (includeDerivers && isDerivation(path)) {
|
|
|
|
|
PathSet outputs = store.queryDerivationOutputs(path);
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & i : outputs)
|
|
|
|
|
if (store.isValidPath(i) && store.queryDeriver(i) == path)
|
|
|
|
|
edges.insert(i);
|
2012-12-20 19:41:44 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} else {
|
|
|
|
|
store.queryReferences(path, edges);
|
|
|
|
|
|
|
|
|
|
if (includeOutputs && isDerivation(path)) {
|
|
|
|
|
PathSet outputs = store.queryDerivationOutputs(path);
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & i : outputs)
|
|
|
|
|
if (store.isValidPath(i)) edges.insert(i);
|
2012-12-20 19:41:44 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (includeDerivers) {
|
|
|
|
|
Path deriver = store.queryDeriver(path);
|
|
|
|
|
if (store.isValidPath(deriver)) edges.insert(deriver);
|
|
|
|
|
}
|
2010-01-25 19:18:44 +02:00
|
|
|
|
}
|
|
|
|
|
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & i : edges)
|
|
|
|
|
computeFSClosure(store, i, paths, flipDirection, includeOutputs, includeDerivers);
|
2005-01-19 13:16:11 +02:00
|
|
|
|
}
|
2005-02-14 19:35:10 +02:00
|
|
|
|
|
|
|
|
|
|
2006-03-06 13:21:15 +02:00
|
|
|
|
Path findOutput(const Derivation & drv, string id)
|
2005-02-14 19:35:10 +02:00
|
|
|
|
{
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & i : drv.outputs)
|
|
|
|
|
if (i.first == id) return i.second.path;
|
2014-08-20 18:00:17 +03:00
|
|
|
|
throw Error(format("derivation has no output ‘%1%’") % id);
|
2005-02-14 19:35:10 +02:00
|
|
|
|
}
|
2006-03-06 13:21:15 +02:00
|
|
|
|
|
|
|
|
|
|
2011-09-01 00:11:50 +03:00
|
|
|
|
void queryMissing(StoreAPI & store, const PathSet & targets,
|
2008-08-04 15:29:04 +03:00
|
|
|
|
PathSet & willBuild, PathSet & willSubstitute, PathSet & unknown,
|
2010-11-17 16:31:42 +02:00
|
|
|
|
unsigned long long & downloadSize, unsigned long long & narSize)
|
2006-03-06 13:21:15 +02:00
|
|
|
|
{
|
2010-11-17 16:31:42 +02:00
|
|
|
|
downloadSize = narSize = 0;
|
2006-03-06 13:21:15 +02:00
|
|
|
|
|
2012-07-31 02:55:41 +03:00
|
|
|
|
PathSet todo(targets.begin(), targets.end()), done;
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
|
|
|
|
|
/* Getting substitute info has high latency when using the binary
|
|
|
|
|
cache substituter. Thus it's essential to do substitute
|
|
|
|
|
queries in parallel as much as possible. To accomplish this
|
|
|
|
|
we do the following:
|
|
|
|
|
|
|
|
|
|
- For all paths still to be processed (‘todo’), we add all
|
|
|
|
|
paths for which we need info to the set ‘query’. For an
|
|
|
|
|
unbuilt derivation this is the output paths; otherwise, it's
|
|
|
|
|
the path itself.
|
|
|
|
|
|
|
|
|
|
- We get info about all paths in ‘query’ in parallel.
|
|
|
|
|
|
|
|
|
|
- We process the results and add new items to ‘todo’ if
|
|
|
|
|
necessary. E.g. if a path is substitutable, then we need to
|
|
|
|
|
get info on its references.
|
|
|
|
|
|
|
|
|
|
- Repeat until ‘todo’ is empty.
|
|
|
|
|
*/
|
|
|
|
|
|
2006-03-06 13:21:15 +02:00
|
|
|
|
while (!todo.empty()) {
|
2012-07-31 02:55:41 +03:00
|
|
|
|
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
PathSet query, todoDrv, todoNonDrv;
|
|
|
|
|
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & i : todo) {
|
|
|
|
|
if (done.find(i) != done.end()) continue;
|
|
|
|
|
done.insert(i);
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
|
2015-07-17 20:24:28 +03:00
|
|
|
|
DrvPathWithOutputs i2 = parseDrvPathWithOutputs(i);
|
2012-11-26 16:39:10 +02:00
|
|
|
|
|
|
|
|
|
if (isDerivation(i2.first)) {
|
|
|
|
|
if (!store.isValidPath(i2.first)) {
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
// FIXME: we could try to substitute p.
|
2015-07-17 20:24:28 +03:00
|
|
|
|
unknown.insert(i);
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
continue;
|
|
|
|
|
}
|
2012-11-26 16:39:10 +02:00
|
|
|
|
Derivation drv = derivationFromPath(store, i2.first);
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
|
|
|
|
|
PathSet invalid;
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & j : drv.outputs)
|
|
|
|
|
if (wantOutput(j.first, i2.second)
|
|
|
|
|
&& !store.isValidPath(j.second.path))
|
|
|
|
|
invalid.insert(j.second.path);
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
if (invalid.empty()) continue;
|
2012-07-31 02:55:41 +03:00
|
|
|
|
|
2015-07-17 20:24:28 +03:00
|
|
|
|
todoDrv.insert(i);
|
2015-06-04 17:04:41 +03:00
|
|
|
|
if (settings.useSubstitutes && substitutesAllowed(drv))
|
2013-06-20 20:26:31 +03:00
|
|
|
|
query.insert(invalid.begin(), invalid.end());
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
else {
|
2015-07-17 20:24:28 +03:00
|
|
|
|
if (store.isValidPath(i)) continue;
|
|
|
|
|
query.insert(i);
|
|
|
|
|
todoNonDrv.insert(i);
|
2008-08-04 14:44:50 +03:00
|
|
|
|
}
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
todo.clear();
|
2012-07-31 02:55:41 +03:00
|
|
|
|
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
SubstitutablePathInfos infos;
|
|
|
|
|
store.querySubstitutablePathInfos(query, infos);
|
|
|
|
|
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & i : todoDrv) {
|
|
|
|
|
DrvPathWithOutputs i2 = parseDrvPathWithOutputs(i);
|
2012-11-26 18:15:09 +02:00
|
|
|
|
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
// FIXME: cache this
|
2012-11-26 18:15:09 +02:00
|
|
|
|
Derivation drv = derivationFromPath(store, i2.first);
|
2006-03-06 13:21:15 +02:00
|
|
|
|
|
2012-11-26 18:15:09 +02:00
|
|
|
|
PathSet outputs;
|
2006-03-06 13:21:15 +02:00
|
|
|
|
bool mustBuild = false;
|
2015-06-04 17:04:41 +03:00
|
|
|
|
if (settings.useSubstitutes && substitutesAllowed(drv)) {
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & j : drv.outputs) {
|
|
|
|
|
if (!wantOutput(j.first, i2.second)) continue;
|
|
|
|
|
if (!store.isValidPath(j.second.path)) {
|
|
|
|
|
if (infos.find(j.second.path) == infos.end())
|
2012-11-26 19:25:12 +02:00
|
|
|
|
mustBuild = true;
|
|
|
|
|
else
|
2015-07-17 20:24:28 +03:00
|
|
|
|
outputs.insert(j.second.path);
|
2012-11-26 19:25:12 +02:00
|
|
|
|
}
|
2012-11-26 18:15:09 +02:00
|
|
|
|
}
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
} else
|
|
|
|
|
mustBuild = true;
|
2006-03-06 13:21:15 +02:00
|
|
|
|
|
|
|
|
|
if (mustBuild) {
|
2012-11-26 18:15:09 +02:00
|
|
|
|
willBuild.insert(i2.first);
|
2006-03-06 13:21:15 +02:00
|
|
|
|
todo.insert(drv.inputSrcs.begin(), drv.inputSrcs.end());
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & j : drv.inputDrvs)
|
|
|
|
|
todo.insert(makeDrvPathWithOutputs(j.first, j.second));
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
} else
|
2012-11-26 18:15:09 +02:00
|
|
|
|
todoNonDrv.insert(outputs.begin(), outputs.end());
|
2006-03-06 13:21:15 +02:00
|
|
|
|
}
|
2012-07-31 02:55:41 +03:00
|
|
|
|
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & i : todoNonDrv) {
|
|
|
|
|
done.insert(i);
|
|
|
|
|
SubstitutablePathInfos::iterator info = infos.find(i);
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
if (info != infos.end()) {
|
2015-07-17 20:24:28 +03:00
|
|
|
|
willSubstitute.insert(i);
|
download-from-binary-cache: parallelise fetching of NAR info files
Getting substitute information using the binary cache substituter has
non-trivial latency overhead. A package or NixOS system configuration
can have hundreds of dependencies, and in the worst case (when the
local info cache is empty) we have to do a separate HTTP request for
each of these. If the ping time to the server is t, getting N info
files will take tN seconds; e.g., with a ping time of 0.1s to
nixos.org, sequentially downloading 1000 info files (a typical NixOS
config) will take at least 100 seconds.
To fix this problem, the binary cache substituter can now perform
requests in parallel. This required changing the substituter
interface to support a function querySubstitutablePathInfos() that
queries multiple paths at the same time, and rewriting queryMissing()
to take advantage of parallelism. (Due to local caching,
parallelising queryMissing() is sufficient for most use cases, since
it's almost always called before building a derivation and thus fills
the local info cache.)
For example, parallelism speeds up querying all 1056 paths in a
particular NixOS system configuration from 116s to 2.6s. It works so
well because the eccentricity of the top-level derivation in the
dependency graph is only 9. So we only need 10 round-trips (when
using an unlimited number of parallel connections) to get everything.
Currently we do a maximum of 150 parallel connections to the server.
Thus it's important that the binary cache server (e.g. nixos.org) has
a high connection limit. Alternatively we could use HTTP pipelining,
but WWW::Curl doesn't support it and libcurl has a hard-coded limit of
5 requests per pipeline.
2012-07-07 02:08:20 +03:00
|
|
|
|
downloadSize += info->second.downloadSize;
|
|
|
|
|
narSize += info->second.narSize;
|
|
|
|
|
todo.insert(info->second.references.begin(), info->second.references.end());
|
2008-08-04 14:44:50 +03:00
|
|
|
|
} else
|
2015-07-17 20:24:28 +03:00
|
|
|
|
unknown.insert(i);
|
2006-03-06 13:21:15 +02:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2006-09-05 00:06:23 +03:00
|
|
|
|
|
2012-07-31 02:55:41 +03:00
|
|
|
|
|
2011-12-30 17:02:50 +02:00
|
|
|
|
static void dfsVisit(StoreAPI & store, const PathSet & paths,
|
|
|
|
|
const Path & path, PathSet & visited, Paths & sorted,
|
|
|
|
|
PathSet & parents)
|
|
|
|
|
{
|
|
|
|
|
if (parents.find(path) != parents.end())
|
2014-08-20 18:00:17 +03:00
|
|
|
|
throw BuildError(format("cycle detected in the references of ‘%1%’") % path);
|
2012-07-31 02:55:41 +03:00
|
|
|
|
|
2011-12-30 17:02:50 +02:00
|
|
|
|
if (visited.find(path) != visited.end()) return;
|
|
|
|
|
visited.insert(path);
|
2011-12-30 19:13:25 +02:00
|
|
|
|
parents.insert(path);
|
2012-07-31 02:55:41 +03:00
|
|
|
|
|
2011-12-30 17:02:50 +02:00
|
|
|
|
PathSet references;
|
|
|
|
|
if (store.isValidPath(path))
|
|
|
|
|
store.queryReferences(path, references);
|
2012-07-31 02:55:41 +03:00
|
|
|
|
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & i : references)
|
2011-12-30 17:02:50 +02:00
|
|
|
|
/* Don't traverse into paths that don't exist. That can
|
|
|
|
|
happen due to substitutes for non-existent paths. */
|
2015-07-17 20:24:28 +03:00
|
|
|
|
if (i != path && paths.find(i) != paths.end())
|
|
|
|
|
dfsVisit(store, paths, i, visited, sorted, parents);
|
2011-12-30 17:02:50 +02:00
|
|
|
|
|
|
|
|
|
sorted.push_front(path);
|
|
|
|
|
parents.erase(path);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Paths topoSortPaths(StoreAPI & store, const PathSet & paths)
|
|
|
|
|
{
|
|
|
|
|
Paths sorted;
|
|
|
|
|
PathSet visited, parents;
|
2015-07-17 20:24:28 +03:00
|
|
|
|
for (auto & i : paths)
|
|
|
|
|
dfsVisit(store, paths, i, visited, sorted, parents);
|
2011-12-30 17:02:50 +02:00
|
|
|
|
return sorted;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2006-09-05 00:06:23 +03:00
|
|
|
|
}
|