gRPC 构建时如何启用 SSL 汇编优化以避免加密流处理性能损失【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc如果你从源码编译 gRPC C构建过程中 SSL 库有时会以OPENSSL_NO_ASM选项编译即禁用汇编代码。根据 doc/ssl-performance.md 的说明这样做在处理加密流时会让性能损失达一个数量级by an order of magnitude。这篇文章面向从源码构建 gRPC C 的读者目标是选对构建系统和构建组合让最终使用的 SSL 库带上汇编优化避免这种性能损失。以下所有结论均来自仓库内的 doc/ssl-performance.md 与 BUILDING.md。先对照官方矩阵你的构建组合是否启用了汇编优化doc/ssl-performance.md 给出了 gRPC C 各构建系统对汇编优化的支持情况构建系统条件平台使用汇编优化Makefile使用 OpenSSL 1.0.2 开发文件all是Makefile其他所有情况all否BazelLinux是BazelMacOS是BazelWindows否CMakeboringssl from submodule默认Linux 或 MacOS是CMakeboringssl from submodule默认generatorNinjaWindows是CMakeboringssl from submodule默认generatorVisual StudioWindows否CMake预装 OpenSSL 1.0.2gRPC_SSL_PROVIDERpackageall是对照这张表可以得出两条选择原则Linux / MacOS 上CMake默认走 boringssl submodule和 Bazel 默认就带汇编优化无需额外配置Windows 是唯一需要主动选择的平台Bazel 不带汇编优化CMake 则取决于生成器——Visual Studio 生成器不带Ninja 生成器才带。准备条件按 BUILDING.md 的要求克隆仓库时包含子模块CMake 构建需要从子模块编译 boringsslBazel 使用不同的依赖模型不需要手动下载子模块$ git clone -b RELEASE_TAG_HERE 你的 grpc 仓库地址 $ cd grpc $ git submodule update --init其中RELEASE_TAG_HERE替换为你要构建的发布标签你的 grpc 仓库地址替换为你实际使用的 grpc 仓库地址。平台依赖以下命令会安装系统包需要相应权限Linux[sudo] apt-get install build-essential autoconf libtool pkg-config使用 CMake 时另需[sudo] apt-get install cmakeWindowsVisual Studio 2022 或更高版本提供 Visual C 编译器、Git、CMake以及 BUILDING.md 明确标注required by boringssl的 NASM加入PATHNinja 为可选项CMake 主路径Linux / MacOS默认即启用汇编优化在 grpc 仓库根目录已初始化子模块下执行 BUILDING.md 给出的命令$ mkdir -p cmake/build $ cd cmake/build $ cmake -DCMAKE_CXX_STANDARD17 ../.. $ make这里../..指向仓库根目录的 CMakeLists.txt。CMake 构建中 SSL 依赖由gRPC_SSL_PROVIDER控制其默认值就是module见 CMakeLists.txt 第 75 行即从third_party/boringssl-with-bazel子模块构建 BoringSSL——这正是官方矩阵中标记为使用汇编优化的组合因此 Linux / MacOS 上不需要任何额外开关。如果希望改用系统预装的 OpenSSL官方矩阵中标记为可用汇编优化的条件是预装 OpenSSL 1.0.2对应 CMake 变量为gRPC_SSL_PROVIDERpackage可参考 BUILDING.md 中-DgRPC_SSL_PROVIDERpackage的用法示例。Windows CMake用 Ninja 生成器才能获得汇编优化这是本主题下最需要主动操作的一条路径。doc/ssl-performance.md 的矩阵明确区分了两种 Windows 生成器Visual Studio 生成器不使用汇编优化Ninja 生成器使用汇编优化。而 cmake/ssl.cmake 揭示了 Ninja / Visual Studio 生成器下汇编优化实际生效的两个前提CMake 版本不低于 3.13并且能在PATH中找到 NASM。缺任意一项时CMake 会发出警告并回退为禁用汇编即设置OPENSSL_NO_ASMCMake 低于 3.13 时WARNING Disabling SSL assembly support because CMake version ${CMAKE_VERSION} is too old (less than 3.13)找不到 NASM 时WARNING Disabling SSL assembly support because NASM could not be found所以配置方法是先确认 NASM 已安装并在PATH中BUILDING.md 给出的安装方式是choco install nasmCMake 版本不低于 3.13然后按 BUILDING.md 的 Ninja 流程构建rem Run from grpc directory after cloning the repo with --recursive or updating submodules. cd cmake md build cd build call %VS170COMNTOOLS%..\..\VC\Auxiliary\Build\vcvarsall.bat x64 cmake -GNinja -DCMAKE_BUILD_TYPERelease -DCMAKE_CXX_STANDARD17 ..\.. cmake --build .其中%VS170COMNTOOLS%是 Visual Studio 2022 安装后提供的环境变量命令原样来自 BUILDING.md使用 Ninja 仍需已安装 Visual C 编译器。验证方式configure 阶段的输出就是判据——出现上述两条警告中的任何一条说明该次构建的 SSL 汇编优化已被禁用分别对应 CMake 过旧、NASM 缺失按前提条件修复后重新 configure两条警告均未出现则按官方矩阵该组合使用汇编优化。如果当前只能使用 Visual Studio 生成器命令见 BUILDING.mdcmake -G Visual Studio 17 2022 -DCMAKE_CXX_STANDARD17 ..后cmake --build . --config Release按矩阵该路径不使用汇编优化文档未提供在该生成器下开启汇编的选项。Bazel 路径Linux / MacOS 默认启用Windows 不启用doc/ssl-performance.md 的矩阵中Bazel 在 Linux 与 MacOS 上标记为使用汇编优化在 Windows 上不启用。BUILDING.md 将 Bazel 列为首选构建系统在仓库根目录执行# Build gRPC C $ bazel build :all注意事项均来自 BUILDING.md需要 Bazel 1.0.0 或更高版本如果使用 Bazel 7 或更高版本需要给 Bazel 命令加上--enable_bzlmodfalse因为 gRPC 尚未完全兼容 bzlmod。也就是说如果你的构建必须跑在 Windows 上且目标是带汇编优化的 SSLBazel 不是可行组合应回到 CMake Ninja 路径。Makefile 路径与预构建包的边界Makefile只有使用 OpenSSL 1.0.2 开发文件这一条件才启用汇编优化其他情况均不启用。同时 BUILDING.md 已声明make不再是推荐构建系统仅作内部用途因此不建议为此专门走 Makefile 路径。其他语言的包C#、Node.JS、Electron、ObjC、PHP、Python、Rubydoc/ssl-performance.md 单独列了矩阵。其中 C#、Node.JS、Python、Electron 的多数 64 位 Linux / MacOS 组合带汇编优化而 C# Linux 32 位、Node.JS Windows、Python Linux 32 位 / MacOS 32 位 / Windows、Ruby、PHP 非源码包、ObjC 源码包iOS均标记为不启用PHP 从源码构建则等同于上面的 Makefile 情况。如果你消费的是这些语言的分发包而非自己编译 gRPC C选型时应以这张表为准。小结Linux / MacOSCMake 默认gRPC_SSL_PROVIDERmoduleboringssl 子模块或 Bazel 构建即可得到带汇编优化的 SSL无需额外配置Windows必须用 CMake Ninja 生成器且满足 CMake ≥ 3.13、NASM 在PATH中两个条件configure 输出中若出现 Disabling SSL assembly support 警告即表示回退到OPENSSL_NO_ASM构建矩阵之外的语言分发包按 doc/ssl-performance.md 的语言/平台表核对不要假定所有分发物都带汇编优化。需要深入了解构建细节可继续查阅 BUILDING.md 的完整构建说明以及 cmake/ssl.cmake 中 SSL provider 的处理逻辑。【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 gRPC 构建时如何启用 SSL 汇编优化以避免加密流处理性能损失？
gRPC 构建时如何启用 SSL 汇编优化以避免加密流处理性能损失【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc如果你从源码编译 gRPC C构建过程中 SSL 库有时会以OPENSSL_NO_ASM选项编译即禁用汇编代码。根据 doc/ssl-performance.md 的说明这样做在处理加密流时会让性能损失达一个数量级by an order of magnitude。这篇文章面向从源码构建 gRPC C 的读者目标是选对构建系统和构建组合让最终使用的 SSL 库带上汇编优化避免这种性能损失。以下所有结论均来自仓库内的 doc/ssl-performance.md 与 BUILDING.md。先对照官方矩阵你的构建组合是否启用了汇编优化doc/ssl-performance.md 给出了 gRPC C 各构建系统对汇编优化的支持情况构建系统条件平台使用汇编优化Makefile使用 OpenSSL 1.0.2 开发文件all是Makefile其他所有情况all否BazelLinux是BazelMacOS是BazelWindows否CMakeboringssl from submodule默认Linux 或 MacOS是CMakeboringssl from submodule默认generatorNinjaWindows是CMakeboringssl from submodule默认generatorVisual StudioWindows否CMake预装 OpenSSL 1.0.2gRPC_SSL_PROVIDERpackageall是对照这张表可以得出两条选择原则Linux / MacOS 上CMake默认走 boringssl submodule和 Bazel 默认就带汇编优化无需额外配置Windows 是唯一需要主动选择的平台Bazel 不带汇编优化CMake 则取决于生成器——Visual Studio 生成器不带Ninja 生成器才带。准备条件按 BUILDING.md 的要求克隆仓库时包含子模块CMake 构建需要从子模块编译 boringsslBazel 使用不同的依赖模型不需要手动下载子模块$ git clone -b RELEASE_TAG_HERE 你的 grpc 仓库地址 $ cd grpc $ git submodule update --init其中RELEASE_TAG_HERE替换为你要构建的发布标签你的 grpc 仓库地址替换为你实际使用的 grpc 仓库地址。平台依赖以下命令会安装系统包需要相应权限Linux[sudo] apt-get install build-essential autoconf libtool pkg-config使用 CMake 时另需[sudo] apt-get install cmakeWindowsVisual Studio 2022 或更高版本提供 Visual C 编译器、Git、CMake以及 BUILDING.md 明确标注required by boringssl的 NASM加入PATHNinja 为可选项CMake 主路径Linux / MacOS默认即启用汇编优化在 grpc 仓库根目录已初始化子模块下执行 BUILDING.md 给出的命令$ mkdir -p cmake/build $ cd cmake/build $ cmake -DCMAKE_CXX_STANDARD17 ../.. $ make这里../..指向仓库根目录的 CMakeLists.txt。CMake 构建中 SSL 依赖由gRPC_SSL_PROVIDER控制其默认值就是module见 CMakeLists.txt 第 75 行即从third_party/boringssl-with-bazel子模块构建 BoringSSL——这正是官方矩阵中标记为使用汇编优化的组合因此 Linux / MacOS 上不需要任何额外开关。如果希望改用系统预装的 OpenSSL官方矩阵中标记为可用汇编优化的条件是预装 OpenSSL 1.0.2对应 CMake 变量为gRPC_SSL_PROVIDERpackage可参考 BUILDING.md 中-DgRPC_SSL_PROVIDERpackage的用法示例。Windows CMake用 Ninja 生成器才能获得汇编优化这是本主题下最需要主动操作的一条路径。doc/ssl-performance.md 的矩阵明确区分了两种 Windows 生成器Visual Studio 生成器不使用汇编优化Ninja 生成器使用汇编优化。而 cmake/ssl.cmake 揭示了 Ninja / Visual Studio 生成器下汇编优化实际生效的两个前提CMake 版本不低于 3.13并且能在PATH中找到 NASM。缺任意一项时CMake 会发出警告并回退为禁用汇编即设置OPENSSL_NO_ASMCMake 低于 3.13 时WARNING Disabling SSL assembly support because CMake version ${CMAKE_VERSION} is too old (less than 3.13)找不到 NASM 时WARNING Disabling SSL assembly support because NASM could not be found所以配置方法是先确认 NASM 已安装并在PATH中BUILDING.md 给出的安装方式是choco install nasmCMake 版本不低于 3.13然后按 BUILDING.md 的 Ninja 流程构建rem Run from grpc directory after cloning the repo with --recursive or updating submodules. cd cmake md build cd build call %VS170COMNTOOLS%..\..\VC\Auxiliary\Build\vcvarsall.bat x64 cmake -GNinja -DCMAKE_BUILD_TYPERelease -DCMAKE_CXX_STANDARD17 ..\.. cmake --build .其中%VS170COMNTOOLS%是 Visual Studio 2022 安装后提供的环境变量命令原样来自 BUILDING.md使用 Ninja 仍需已安装 Visual C 编译器。验证方式configure 阶段的输出就是判据——出现上述两条警告中的任何一条说明该次构建的 SSL 汇编优化已被禁用分别对应 CMake 过旧、NASM 缺失按前提条件修复后重新 configure两条警告均未出现则按官方矩阵该组合使用汇编优化。如果当前只能使用 Visual Studio 生成器命令见 BUILDING.mdcmake -G Visual Studio 17 2022 -DCMAKE_CXX_STANDARD17 ..后cmake --build . --config Release按矩阵该路径不使用汇编优化文档未提供在该生成器下开启汇编的选项。Bazel 路径Linux / MacOS 默认启用Windows 不启用doc/ssl-performance.md 的矩阵中Bazel 在 Linux 与 MacOS 上标记为使用汇编优化在 Windows 上不启用。BUILDING.md 将 Bazel 列为首选构建系统在仓库根目录执行# Build gRPC C $ bazel build :all注意事项均来自 BUILDING.md需要 Bazel 1.0.0 或更高版本如果使用 Bazel 7 或更高版本需要给 Bazel 命令加上--enable_bzlmodfalse因为 gRPC 尚未完全兼容 bzlmod。也就是说如果你的构建必须跑在 Windows 上且目标是带汇编优化的 SSLBazel 不是可行组合应回到 CMake Ninja 路径。Makefile 路径与预构建包的边界Makefile只有使用 OpenSSL 1.0.2 开发文件这一条件才启用汇编优化其他情况均不启用。同时 BUILDING.md 已声明make不再是推荐构建系统仅作内部用途因此不建议为此专门走 Makefile 路径。其他语言的包C#、Node.JS、Electron、ObjC、PHP、Python、Rubydoc/ssl-performance.md 单独列了矩阵。其中 C#、Node.JS、Python、Electron 的多数 64 位 Linux / MacOS 组合带汇编优化而 C# Linux 32 位、Node.JS Windows、Python Linux 32 位 / MacOS 32 位 / Windows、Ruby、PHP 非源码包、ObjC 源码包iOS均标记为不启用PHP 从源码构建则等同于上面的 Makefile 情况。如果你消费的是这些语言的分发包而非自己编译 gRPC C选型时应以这张表为准。小结Linux / MacOSCMake 默认gRPC_SSL_PROVIDERmoduleboringssl 子模块或 Bazel 构建即可得到带汇编优化的 SSL无需额外配置Windows必须用 CMake Ninja 生成器且满足 CMake ≥ 3.13、NASM 在PATH中两个条件configure 输出中若出现 Disabling SSL assembly support 警告即表示回退到OPENSSL_NO_ASM构建矩阵之外的语言分发包按 doc/ssl-performance.md 的语言/平台表核对不要假定所有分发物都带汇编优化。需要深入了解构建细节可继续查阅 BUILDING.md 的完整构建说明以及 cmake/ssl.cmake 中 SSL provider 的处理逻辑。【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考