python / python/pyperformance

asyncio_websockets tests the implementation of `zlib`, not of Python

未关闭
#460 2 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

主要语言
Python
星标
1k
派生
203
平均合并
1 小时 20 分钟
30 天内合并 PR
2

描述

I found out that the asyncio_websockets benchmark spends ~87% of runtime in zlib (i.e. in the shared library libz.so), or whatever compression library is the default on the system-under-test.

In other words, asyncio_websockets tests the implementation of compression/decompression algorithms rather than anything to do with the Python interpreter or the websockets Python module. Websockets indeed enables compression by default: https://websockets.readthedocs.io/en/stable/topics/compression.html, excerpt from that official documentation:

connect() and serve() enable compression by default because the reduction in network bandwidth is usually worth the additional memory and CPU cost.

Problem

I believe this benchmark may not be measuring what's intended in its current form. For example, a replacement of zlib with zlib-ng or zlib-rs (which are newer drop-in replacement of zlib) may significantly affect the performance score of this benchmark, even though nothing changed in Python and/or websockets implementations. It is hard to root cause such performance modification, without knowing this detail about the asyncio_websockets benchmark.

It is also used in e.g. Phoronix testing, which may lead to unexpected conclusions for readers who aren't aware of this detail. Example: https://www.phoronix.com/review/cachyos-ubuntu-2510-f43/5.

Solutions

I see the following solutions:

  1. Clearly document this behavior in https://pyperformance.readthedocs.io/benchmarks.html (in fact, there is no mention of websockets benchmark at all).
  2. Remove this benchmark, since the workload is dominated by native zlib rather than Python or websockets logic.
  3. Modify this benchmark to disable compression, as described here: https://websockets.readthedocs.io/en/stable/topics/compression.html#configuring-compression

I'd lean towards option 3 (disabling compression) as it preserves the benchmark's intent while removing the zlib dependency from results. I'm happy to submit a PR if the maintainers agree.

Reproducing

I ran it with a Amazon Linux 2023 docker container (OS distro similar to Fedora):

docker run --rm -it amazonlinux:2023 /bin/bash # -->

dnf install -y pip perf dnf-utils
dnf debuginfo-install zlib python3.9
python3 -m pip install pyperformance
python3 -m pip install websockets==11.0.3 pyperf==2.6.3

perf record -g --call-graph dwarf -- \
  python3 -u /usr/local/lib/python3.9/site-packages/pyperformance/data-files/benchmarks/bm_asyncio_websockets/run_benchmark.py

After running the benchmark, we can examine the resulting perf.data file:

$ perf report --hierarchy
...
-   99.93%        python3
   -   87.22%        libz.so.1.2.11
      +   40.11%        [.] inflate_fast
      +   36.28%        [.] deflate_slow
      ...
   +    5.20%        libpython3.9.so.1.0
   +    1.60%        libc.so.6
   ...

P.S. Thank you for maintaining the pyperformance project!

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

从 pyperformance/data-files/benchmarks/bm_asyncio_websockets/run_benchmark.py 开始,并使用 perf 重现 profile,以确认 zlib 所占的比例。查看链接的 websockets 压缩指南和 benchmark 文档的入口。完成的标准是:maintainers 选择的解决方案已实现,并且 benchmark 的压缩行为已得到清晰记录,或已从测量的工作负载中排除。

由索引模型根据 Issue 内容生成。

评估

技术栈
python
领域
performance, testing-qa
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
活跃
描述清晰度
基本清楚
新手友好度
48/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。