网站怎么做订单,wordpress ueditor 代码 转义,2023年阳性最新上班政策,17做网店这个网站好不好原理
您可以将服务器设置为构建输出#xff08;即这些操作输出#xff09;的远程缓存。这些输出由输出文件名列表及其内容的哈希值组成。借助远程缓存#xff0c;您可以重复使用其他用户的 build 中的构建输出#xff0c;而不是在本地构建每个新输出。
增量构建极大的提升…原理
您可以将服务器设置为构建输出即这些操作输出的远程缓存。这些输出由输出文件名列表及其内容的哈希值组成。借助远程缓存您可以重复使用其他用户的 build 中的构建输出而不是在本地构建每个新输出。
增量构建极大的提升了本地研发的构建效率但有些场合它的效果不是很好例如 CI 环境通常采用“干净”的容器此时没有上一次的构建数据只能全量构建。
即使是本地研发如果从远端同步代码时修改了全局参数也会导致增量构建失效。
缓存 (Remote Cache) 与远程执行 (Remote Execution) 可以很好的解决这个问题。
前面聊到Action 满足封闭性即相同的 Action 信息一定产生相同的结果。因此可以建立 Action 到 ActionResult 的映射。为了便于索引Bazel 把 Action 信息通过 sha256 哈希算法压缩成摘要 (Digest)把 Digest 到 ActionResult 的映射存储在云端就可以实现 Action 的跨构建共享。 Action 共享示意图
这里的 Storage 是完全基于内容寻址的即“一个 Digest 唯一对应一个 ActionResult”内容寻址的好处是不容易污染存储空间因为修改任何一行代码会计算出不同的 Digest不用担心污染别人的 ActionResult。内容寻址的存储引擎被称为Content Addressable Storage(CAS)如果没有特别强调本文后续使用简称 CAS 来表述。
CAS 里存放的任何文件无论是 Action 的 Meta 信息还是编译产物二进制都被称为 Blob。
为保证 CAS 的存储空间被有效利用通常会使用 LRU 算法管理 CAS 里存储的 Blob当存储空间写满时最久没被访问的 Blob 就会被自动淘汰这样就保证了空间里的 Blob 是最活跃的。
部署
部署运行
前面讲了Bazel的基本本地使用和原理但是我们知道Bazel最重要的是支持缓存和分布式远程执行那么这一节主要就是讲如何让bazel使用缓存。
要能够缓存Bazel每个action的输出我们就要一个server来实现remote cache用于存储action的输出。这些输出实际上是一堆文件输出对应的hash值。总体来说我们需要满足三个前提 设置一个server作为cache backend 配置Bazel build去使用cache Bazel版本要在0.10.0以上
Cache本身会存储两种数据 action cache或者说实际上是一个acton-action result的map映射表 一个可寻址(addressable)的输出文件存储系统
https://docs.bazel.build/versions/master/remote-caching.html 中对Bazel Remote Cache的使用和工作有更详细的介绍就不重复了。这里直接讲到底怎么设置一个Bazel Remote Cache Server. 在上面这个链接中提到了三种方式 NGINX的WebDAV模块 开源的bazel-remote Google Cloud Storage
这里我们直接选择第二种开源的bazel-remote以便可能的定制及更好理解内部实现。
buchgr/bazel-remote
这里我们不用去重新编译运行直接下载对应的docker镜像并运行即可
$docker pull buchgr/bazel-remote-cache
bazel-remote支持grpc和http的接口调用但注意docker内部应用的http接口应该是8080而不是9090官方文档有误。
创建一个目录cache, 然后启动docker容器如下
pathpwd;docker run -v $path/cache:/data -p 9090:8080 -p 9092:9092 buchgr/bazel-remote-cache
备注 需要提前创建cache目录或者失败后对目录加777权限并用-u指定当前用户的uid和gid否则会报mkdir /data/cas.v2:permission denied。即docker run -u $uid:$gid -v xxx 建议用--max_size限制缓存目录的大小。一般在命令最后加上 --maz_size50
我们可以看到一堆输出
2020/10/13 16:12:20 bazel-remote built with go1.14.5 from git commit cc9030667416ab63d89b9fbf543f0243292009b4.
2020/10/13 16:12:20 Initial RLIMIT_NOFILE cur: 1048576 max: 1048576
2020/10/13 16:12:20 Setting RLIMIT_NOFILE cur: 1048576 max: 1048576
2020/10/13 16:12:21 Migrating files (if any) to new directory structure: /data/ac
2020/10/13 16:12:21 Migrating files (if any) to new directory structure: /data/cas
2020/10/13 16:12:21 Loading existing files in /data.
2020/10/13 16:12:23 Sorting cache files by atime.
2020/10/13 16:12:23 Building LRU index.
2020/10/13 16:12:23 Finished loading disk cache files.
2020/10/13 16:12:23 Loaded 0 existing disk cache items.
2020/10/13 16:12:23 Starting HTTP server on address :8080
2020/10/13 16:12:23 HTTP AC validation: enabled
2020/10/13 16:12:23 Starting HTTP server for profiling on address :6060
2020/10/13 16:12:23 Starting gRPC server on address :9092
2020/10/13 16:12:23 gRPC AC dependency checks: enabled
2020/10/13 16:12:23 experimental gRPC remote asset API: disabled
然后可以通过其/status接口来查看是否正常启动
$curl http://localhost:9090/status
{CurrSize: 0,MaxSize: 5368709120,NumFiles: 0,ServerTime: 1602605641,GitCommit: cc9030667416ab63d89b9fbf543f0243292009b4
}
另外我们也可以查看cache目录下是否生成了对应文件 这时就可以在运行bazel build的时候指定remote cache server的地址 $bazel build //src/main:app --remote_cachehttp://localhost:9090
INFO: Invocation ID: a9a389d2-1e9f-4878-b65b-586e7b70fa35
INFO: Analyzed target //src/main:app (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //src/main:app up-to-date:bazel-bin/src/main/app_deploy.jarbazel-bin/src/main/app_unsigned.apkbazel-bin/src/main/app.apk
INFO: Elapsed time: 3.271s, Critical Path: 3.02s
INFO: 12 processes: 9 darwin-sandbox, 3 worker.
INFO: Build completed successfully, 13 total actions
备注
为了避免本地缓存对远程缓存的影响在执行构建前清理本地缓存。运行以下命令可删除输出文件并可选择停止服务器。
bazel clean
检查缓存命中率
在 Bazel 运行的标准输出结果中查看列出进程的 INFO 行该进程大致对应于 Bazel 操作。运行操作所在的行详细信息。查找 remote 标签该标签表示远程执行的操作、linux-sandbox 在本地沙盒内执行的操作以及用于其他执行策略的其他值。操作来自远程缓存的操作会显示为 remote cache hit。
例如
INFO: 11 processes: 6 remote cache hit, 3 internal, 2 remote.
在此示例中有 6 次远程缓存命中有 2 项操作没有缓存命中且远程执行了这些命中。这 3 个内部部分可以忽略。 它通常是微小的内部操作例如创建符号链接。此摘要不包含本地缓存命中。如果获得 0 个进程或低于预期的数字请运行 bazel clean后跟构建/测试命令。
在docker一侧我们可以看到输出 可以看到cache主要是通过http put/get并使用hash作为key来进行对应结果的查找。 我们重复几次bazel build后可以看到耗时很短只有不到0.3秒:
INFO: Analyzed target //src/main:app (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //src/main:app up-to-date:bazel-bin/src/main/app_deploy.jarbazel-bin/src/main/app_unsigned.apkbazel-bin/src/main/app.apk
INFO: Elapsed time: 0.286s, Critical Path: 0.03s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
这显然是cache的作用我们也可以在BUILD文件中禁止cache。这实际上是对rule的tags设置我们在以后再讲如何定义rule我们在这里可以尝试对java_library这个rule添加tag禁止cache。修改src/main/java/com/example/bazel/util/BUILD中的java_library属性如下 这样bazel就不会对该BUILD的结果进行缓存读者可以自行尝试对比这里就不过多展示实验结果。 排查缓存命中问题
如果您没有获得预期的缓存命中率请执行以下操作
确保重新运行相同的构建/测试命令会生成缓存命中
1.运行您希望填充缓存的构建和/或测试。首次在特定堆栈上运行新 build 时应该不会有任何远程缓存命中。在远程执行过程中操作结果会存储在缓存中后续运行结果应该会提取这些结果。
2.运行 bazel clean。此命令会清理您的本地缓存这样一来您便可以调查远程缓存命中而结果不会被本地缓存命中遮盖。
3.在同一机器上运行调查的 build 和测试。
4.请查看 INFO 行了解缓存命中率。如果您看到除 remote cache hit 和 internal 以外的任何进程则表明您的缓存已正确填充和访问。在这种情况下请跳到下一部分。
5.可能的差异来源是 build 中非封闭的内容导致操作在两次运行中接收不同的操作键。如需找到这些操作请执行以下操作
a.重新运行相关 build 或测试以获取执行日志
bazel clean
bazel --optional-flags build //your:target --execution_log_binary_file/tmp/exec1.log
b. 在两次运行之间比较执行日志。确保两个日志文件中的操作完全相同。 通过差异您可以了解两次运行之间的变化。请更新您的 build 以消除这些差异。
如果您能够解决缓存问题并且现在重复运行会生成所有缓存命中请跳到下一部分。
如果您的操作 ID 相同但没有任何缓存命中则表示配置中有某项内容阻止了缓存。继续完成此部分检查是否存在常见问题。
如果您不需要区分执行日志则可以改用直观易懂的 --execution_log_json_file 标志。它包含执行时间并且不能保证顺序因此无法用于稳定差异比较。
6.检查执行日志中的所有操作是否均将 cacheable 设置为 true。如果指定操作的执行日志中未显示 cacheable则表示相应规则在 BUILD 文件的定义中可能有 no-cache 标记。查看执行日志中直观易懂的 progress_message 字段以帮助确定操作的来源。
7.如果操作相同且为 cacheable 但没有缓存命中则您的命令行中可能包含针对 build 停用缓存查询的 --noremote_accept_cached。 如果难以确定实际命令行请使用 Build Event Protocol 中的规范命令行如下所示 a.将 --build_event_text_file/tmp/bep.txt 添加到 Bazel 命令中以获取日志的文本版本。 b. 打开日志的文本版本然后使用 command_line_label: canonical 搜索 structured_command_line 消息。 展开之后会列出所有选项。 c.搜索 remote_accept_cached 并检查其是否已设置为 false。 d. 如果 remote_accept_cached 为 false请确定它位于 false 的位置在命令行中或在 bazelrc 文件中。
确保可以跨机器进行缓存
在同一台计算机上按预期执行缓存命中后在其他机器上运行相同的构建/测试。如果您怀疑缓存未在机器间运行请执行以下操作
1.对构建稍作修改以避免命中现有缓存。
2.在第一台机器上运行构建
bazel clean
bazel ... build ... --execution_log_binary_file/tmp/exec1.log
3.在第二台机器上运行 build确保包含第 1 步中所做的修改
bazel clean
bazel ... build ... --execution_log_binary_file/tmp/exec1.log
4.比较两次运行的执行日志。如果日志不相同请调查构建配置是否存在差异以及主机环境中是否存在泄露到任一 build 中的属性。
比较执行日志
执行日志包含构建期间执行的所有操作的记录。每个操作都有一个 SpawnExec 元素其中包含操作键中的所有信息。因此如果日志相同则操作缓存键也相同。
如需比较两个未按预期共享缓存命中的构建的日志请执行以下操作
1.从每个 build 中获取执行日志并将其存储为 /tmp/exec1.log 和 /tmp/exec2.log。
2. 下载 Bazel 源代码然后使用以下命令导航到 Bazel 文件夹。您需要使用源代码来使用 execlog 解析器解析执行日志。
git clone https://github.com/bazelbuild/bazel.git
cd bazel
3.使用执行日志解析器将日志转换为文本。以下调用还会对第二个日志中的操作进行排序以匹配第一个日志中的操作顺序以方便比较。
bazel build src/tools/execlog:parser
bazel-bin/src/tools/execlog/parser \--log_path/tmp/exec1.log \--log_path/tmp/exec2.log \--output_path/tmp/exec1.log.txt \--output_path/tmp/exec2.log.txt
4.使用您最喜欢的文本差异为 /tmp/exec1.log.txt 和 /tmp/exec2.log.txt。
实际上remote caching只是最基本的一个结果缓存机制部署和使用都很简单这里也只是对此进行快捷说明。小团队完全可以用这种方式来部分提升效率。而远程执行(Remote Execution)往往集成了缓存功能因此在实际大型团队部署中一般不会专门对Remote Cache创建server。我们在下一节来介绍Remote Execution. 本文属于如下文章中的子章节
bazel学习系列章节汇总_m0_74043383的博客-CSDN博客
