Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
#include "derivations.hh"
|
2012-04-30 23:15:34 +00:00
|
|
|
#include "globals.hh"
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
#include "local-store.hh"
|
|
|
|
#include "store-api.hh"
|
2016-07-21 12:13:35 +00:00
|
|
|
#include "thread-pool.hh"
|
2006-09-04 21:06:23 +00:00
|
|
|
|
|
|
|
|
|
|
|
namespace nix {
|
2004-06-18 18:09:32 +00:00
|
|
|
|
|
|
|
|
2016-11-10 16:45:04 +00:00
|
|
|
void Store::computeFSClosure(const PathSet & startPaths,
|
2016-09-16 16:54:14 +00:00
|
|
|
PathSet & paths_, bool flipDirection, bool includeOutputs, bool includeDerivers)
|
2005-01-19 11:16:11 +00:00
|
|
|
{
|
2016-09-16 16:54:14 +00:00
|
|
|
struct State
|
|
|
|
{
|
|
|
|
size_t pending;
|
|
|
|
PathSet & paths;
|
|
|
|
std::exception_ptr exc;
|
|
|
|
};
|
|
|
|
|
|
|
|
Sync<State> state_(State{0, paths_, 0});
|
2012-12-20 17:41:44 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
std::function<void(const Path &)> enqueue;
|
2012-12-20 17:41:44 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
std::condition_variable done;
|
2012-12-20 17:41:44 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
enqueue = [&](const Path & path) -> void {
|
2016-07-21 12:13:35 +00:00
|
|
|
{
|
|
|
|
auto state(state_.lock());
|
2016-09-16 16:54:14 +00:00
|
|
|
if (state->exc) return;
|
|
|
|
if (state->paths.count(path)) return;
|
|
|
|
state->paths.insert(path);
|
|
|
|
state->pending++;
|
2012-12-20 17:41:44 +00:00
|
|
|
}
|
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
queryPathInfo(path,
|
|
|
|
[&, path](ref<ValidPathInfo> info) {
|
|
|
|
// FIXME: calls to isValidPath() should be async
|
2012-12-20 17:41:44 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
if (flipDirection) {
|
2016-07-21 12:13:35 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
PathSet referrers;
|
|
|
|
queryReferrers(path, referrers);
|
|
|
|
for (auto & ref : referrers)
|
|
|
|
if (ref != path)
|
|
|
|
enqueue(ref);
|
2016-07-21 12:13:35 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
if (includeOutputs)
|
|
|
|
for (auto & i : queryValidDerivers(path))
|
|
|
|
enqueue(i);
|
2016-07-21 12:13:35 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
if (includeDerivers && isDerivation(path))
|
|
|
|
for (auto & i : queryDerivationOutputs(path))
|
|
|
|
if (isValidPath(i) && queryPathInfo(i)->deriver == path)
|
|
|
|
enqueue(i);
|
2016-07-21 12:13:35 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
} else {
|
2016-07-21 12:13:35 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
for (auto & ref : info->references)
|
|
|
|
if (ref != path)
|
|
|
|
enqueue(ref);
|
2016-07-21 12:13:35 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
if (includeOutputs && isDerivation(path))
|
|
|
|
for (auto & i : queryDerivationOutputs(path))
|
|
|
|
if (isValidPath(i)) enqueue(i);
|
2016-07-21 12:13:35 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
if (includeDerivers && isValidPath(info->deriver))
|
|
|
|
enqueue(info->deriver);
|
2016-07-21 12:13:35 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
auto state(state_.lock());
|
|
|
|
assert(state->pending);
|
|
|
|
if (!--state->pending) done.notify_one();
|
|
|
|
}
|
|
|
|
|
|
|
|
},
|
|
|
|
|
|
|
|
[&, path](std::exception_ptr exc) {
|
|
|
|
auto state(state_.lock());
|
|
|
|
if (!state->exc) state->exc = exc;
|
|
|
|
assert(state->pending);
|
|
|
|
if (!--state->pending) done.notify_one();
|
|
|
|
});
|
2016-07-21 12:13:35 +00:00
|
|
|
};
|
2012-12-20 17:41:44 +00:00
|
|
|
|
2016-11-10 16:45:04 +00:00
|
|
|
for (auto & startPath : startPaths)
|
|
|
|
enqueue(startPath);
|
2010-01-25 17:18:44 +00:00
|
|
|
|
2016-09-16 16:54:14 +00:00
|
|
|
{
|
|
|
|
auto state(state_.lock());
|
|
|
|
while (state->pending) state.wait(done);
|
|
|
|
if (state->exc) std::rethrow_exception(state->exc);
|
|
|
|
}
|
2005-02-14 17:35:10 +00:00
|
|
|
}
|
2006-03-06 11:21:15 +00:00
|
|
|
|
|
|
|
|
2016-11-10 16:45:04 +00:00
|
|
|
void Store::computeFSClosure(const Path & startPath,
|
|
|
|
PathSet & paths_, bool flipDirection, bool includeOutputs, bool includeDerivers)
|
|
|
|
{
|
|
|
|
computeFSClosure(PathSet{startPath}, paths_, flipDirection, includeOutputs, includeDerivers);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-02-04 13:48:42 +00:00
|
|
|
void Store::queryMissing(const PathSet & targets,
|
2016-07-21 15:40:40 +00:00
|
|
|
PathSet & willBuild_, PathSet & willSubstitute_, PathSet & unknown_,
|
|
|
|
unsigned long long & downloadSize_, unsigned long long & narSize_)
|
2006-03-06 11:21:15 +00:00
|
|
|
{
|
2016-07-21 15:40:40 +00:00
|
|
|
downloadSize_ = narSize_ = 0;
|
2006-03-06 11:21:15 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
ThreadPool pool;
|
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-06 23:08:20 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
struct State
|
|
|
|
{
|
|
|
|
PathSet done;
|
|
|
|
PathSet & unknown, & willSubstitute, & willBuild;
|
|
|
|
unsigned long long & downloadSize;
|
|
|
|
unsigned long long & narSize;
|
|
|
|
};
|
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-06 23:08:20 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
struct DrvState
|
|
|
|
{
|
|
|
|
size_t left;
|
|
|
|
bool done = false;
|
|
|
|
PathSet outPaths;
|
|
|
|
DrvState(size_t left) : left(left) { }
|
|
|
|
};
|
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-06 23:08:20 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
Sync<State> state_(State{PathSet(), unknown_, willSubstitute_, willBuild_, downloadSize_, narSize_});
|
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-06 23:08:20 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
std::function<void(Path)> doPath;
|
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-06 23:08:20 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
auto mustBuildDrv = [&](const Path & drvPath, const Derivation & drv) {
|
|
|
|
{
|
|
|
|
auto state(state_.lock());
|
|
|
|
state->willBuild.insert(drvPath);
|
|
|
|
}
|
2012-07-30 23:55:41 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
for (auto & i : drv.inputDrvs)
|
|
|
|
pool.enqueue(std::bind(doPath, makeDrvPathWithOutputs(i.first, i.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-06 23:08:20 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
auto checkOutput = [&](
|
|
|
|
const Path & drvPath, ref<Derivation> drv, const Path & outPath, ref<Sync<DrvState>> drvState_)
|
|
|
|
{
|
|
|
|
if (drvState_->lock()->done) return;
|
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-06 23:08:20 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
SubstitutablePathInfos infos;
|
|
|
|
querySubstitutablePathInfos({outPath}, infos);
|
2012-11-26 14:39:10 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
if (infos.empty()) {
|
|
|
|
drvState_->lock()->done = true;
|
|
|
|
mustBuildDrv(drvPath, *drv);
|
|
|
|
} else {
|
|
|
|
{
|
|
|
|
auto drvState(drvState_->lock());
|
|
|
|
if (drvState->done) return;
|
|
|
|
assert(drvState->left);
|
|
|
|
drvState->left--;
|
|
|
|
drvState->outPaths.insert(outPath);
|
|
|
|
if (!drvState->left) {
|
|
|
|
for (auto & path : drvState->outPaths)
|
|
|
|
pool.enqueue(std::bind(doPath, 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-06 23:08:20 +00:00
|
|
|
}
|
2008-08-04 11:44:50 +00: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-06 23:08:20 +00:00
|
|
|
}
|
2016-07-21 15:40:40 +00: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-06 23:08:20 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
doPath = [&](const Path & path) {
|
2012-07-30 23:55:41 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
{
|
|
|
|
auto state(state_.lock());
|
|
|
|
if (state->done.count(path)) return;
|
|
|
|
state->done.insert(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-06 23:08:20 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
DrvPathWithOutputs i2 = parseDrvPathWithOutputs(path);
|
|
|
|
|
|
|
|
if (isDerivation(i2.first)) {
|
|
|
|
if (!isValidPath(i2.first)) {
|
|
|
|
// FIXME: we could try to substitute the derivation.
|
|
|
|
auto state(state_.lock());
|
|
|
|
state->unknown.insert(path);
|
|
|
|
return;
|
|
|
|
}
|
2012-11-26 16:15:09 +00:00
|
|
|
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
Derivation drv = derivationFromPath(i2.first);
|
2006-03-06 11:21:15 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
PathSet invalid;
|
|
|
|
for (auto & j : drv.outputs)
|
|
|
|
if (wantOutput(j.first, i2.second)
|
|
|
|
&& !isValidPath(j.second.path))
|
|
|
|
invalid.insert(j.second.path);
|
|
|
|
if (invalid.empty()) return;
|
|
|
|
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
if (settings.useSubstitutes && drv.substitutesAllowed()) {
|
2016-07-21 15:40:40 +00:00
|
|
|
auto drvState = make_ref<Sync<DrvState>>(DrvState(invalid.size()));
|
|
|
|
for (auto & output : invalid)
|
|
|
|
pool.enqueue(std::bind(checkOutput, i2.first, make_ref<Derivation>(drv), output, drvState));
|
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-06 23:08:20 +00:00
|
|
|
} else
|
2016-07-21 15:40:40 +00:00
|
|
|
mustBuildDrv(i2.first, drv);
|
2006-03-06 11:21:15 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
} else {
|
2012-07-30 23:55:41 +00:00
|
|
|
|
2016-07-21 15:40:40 +00:00
|
|
|
if (isValidPath(path)) return;
|
|
|
|
|
|
|
|
SubstitutablePathInfos infos;
|
|
|
|
querySubstitutablePathInfos({path}, infos);
|
|
|
|
|
|
|
|
if (infos.empty()) {
|
|
|
|
auto state(state_.lock());
|
|
|
|
state->unknown.insert(path);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto info = infos.find(path);
|
|
|
|
assert(info != infos.end());
|
|
|
|
|
|
|
|
{
|
|
|
|
auto state(state_.lock());
|
|
|
|
state->willSubstitute.insert(path);
|
|
|
|
state->downloadSize += info->second.downloadSize;
|
|
|
|
state->narSize += info->second.narSize;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (auto & ref : info->second.references)
|
|
|
|
pool.enqueue(std::bind(doPath, ref));
|
2006-03-06 11:21:15 +00:00
|
|
|
}
|
2016-07-21 15:40:40 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
for (auto & path : targets)
|
|
|
|
pool.enqueue(std::bind(doPath, path));
|
|
|
|
|
|
|
|
pool.process();
|
2006-03-06 11:21:15 +00:00
|
|
|
}
|
2006-09-04 21:06:23 +00:00
|
|
|
|
2012-07-30 23:55:41 +00:00
|
|
|
|
2016-02-04 13:48:42 +00:00
|
|
|
Paths Store::topoSortPaths(const PathSet & paths)
|
2011-12-30 15:02:50 +00:00
|
|
|
{
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
Paths sorted;
|
|
|
|
PathSet visited, parents;
|
2012-07-30 23:55:41 +00:00
|
|
|
|
2016-06-03 02:23:13 +00:00
|
|
|
std::function<void(const Path & path, const Path * parent)> dfsVisit;
|
2012-07-30 23:55:41 +00:00
|
|
|
|
2016-06-03 02:23:13 +00:00
|
|
|
dfsVisit = [&](const Path & path, const Path * parent) {
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
if (parents.find(path) != parents.end())
|
2017-07-30 11:27:57 +00:00
|
|
|
throw BuildError(format("cycle detected in the references of '%1%' from '%2%'") % path % *parent);
|
2012-07-30 23:55:41 +00:00
|
|
|
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
if (visited.find(path) != visited.end()) return;
|
|
|
|
visited.insert(path);
|
|
|
|
parents.insert(path);
|
2011-12-30 15:02:50 +00:00
|
|
|
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
PathSet references;
|
2016-04-19 16:50:15 +00:00
|
|
|
try {
|
|
|
|
references = queryPathInfo(path)->references;
|
|
|
|
} catch (InvalidPath &) {
|
|
|
|
}
|
2011-12-30 15:02:50 +00:00
|
|
|
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
for (auto & i : references)
|
|
|
|
/* Don't traverse into paths that don't exist. That can
|
|
|
|
happen due to substitutes for non-existent paths. */
|
|
|
|
if (i != path && paths.find(i) != paths.end())
|
2016-06-03 02:23:13 +00:00
|
|
|
dfsVisit(i, &path);
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
|
|
|
|
sorted.push_front(path);
|
|
|
|
parents.erase(path);
|
|
|
|
};
|
2011-12-30 15:02:50 +00:00
|
|
|
|
2015-07-17 17:24:28 +00:00
|
|
|
for (auto & i : paths)
|
2016-06-03 02:23:13 +00:00
|
|
|
dfsVisit(i, nullptr);
|
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 13:28:26 +00:00
|
|
|
|
2011-12-30 15:02:50 +00:00
|
|
|
return sorted;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-09-04 21:06:23 +00:00
|
|
|
}
|