Django+Uwsgi环境下stage_block API上传文件块异常缓慢问题排查

1. Base64编码方式的额外开销 #

你在生成block_id时使用了base64.encodestring，这个方法在Python 2.7中会每76个字符插入换行符，后续的strip()操作虽然会去除换行，但额外的格式化处理会产生不必要的性能损耗。直接调用场景中批量处理没凸显问题，但在Django单次小块请求的场景下被放大。

解决办法：
替换base64.encodestring为base64.b64encode，直接生成无换行的base64字符串：

block_id = base64.b64encode(str(idx)).strip()

2. Uwsgi环境下的网络连接复用问题 #

直接调用时，BlobClient会复用HTTP连接池中的连接；但在Uwsgi的多进程/多线程模型下，每次请求创建的BlobClient可能无法有效复用连接，导致每次stage_block都需要重新建立TCP连接、SSL握手，大幅增加小文件块的请求耗时。

解决办法：

• 全局复用ContainerClient：确保ContainerClient在Django项目启动时初始化一次（比如放在模块顶层或Django的ready()方法中），避免每次请求重复创建客户端实例。
• 调整连接池大小：创建Client时显式设置max_connections参数，增大连接池容量，提升复用率：

container = ContainerClient(account_url=********,
                            container_name="test",
                            max_connections=100)

3. Uwsgi配置的网络参数限制 #

你的Uwsgi配置中buffer-size=65536（64KB），如果POST的base64数据接近或超过这个值，会导致Uwsgi分段读取请求数据，增加解析耗时。另外，未启用HTTP长连接也可能导致连接频繁重建。

解决办法：

• 增大buffer-size到128KB或256KB：

buffer-size = 131072

• 添加HTTP长连接配置：

http-keepalive = true

4. Python 2.7与Azure SDK的兼容性瓶颈 #

azure-storage-blob==12.3.2对Python 2.7的支持属于维护阶段，部分内部逻辑（如加密、请求序列化）在Python 2.7环境下可能存在性能缺陷，尤其是在多线程的Uwsgi场景中，GIL的限制会放大这些缺陷。

解决办法：

• 尝试降级Azure SDK到适配Python 2.7的稳定版本（比如azure-storage-blob==2.1.0，注意这是旧版SDK，API会有差异，需要调整代码）。
• 用性能分析工具定位瓶颈：在process_chunk中加入cProfile分析，明确耗时环节：

import cProfile
import pstats

def process_chunk(request):
    pr = cProfile.Profile()
    pr.enable()
    
    # 原有业务代码
    
    pr.disable()
    stats = pstats.Stats(pr)
    stats.sort_stats('cumulative')
    stats.print_stats(10)  # 打印前10个最耗时的函数

5. DNS解析或SSL握手阻塞 #

Uwsgi所在服务器的DNS解析速度慢，或者SSL证书验证过程耗时过长，都会导致stage_block请求的前期准备时间被拉长，甚至接近harakiri的90秒超时阈值。

解决办法：

• 测试直接使用Azure存储账户的IP地址替换account_url中的域名，验证是否是DNS问题。
• 临时禁用SSL验证（仅用于测试，生产环境不建议），看是否提速：

container = ContainerClient(account_url=********,
                            container_name="test",
                            verify=False)

内容的提问来源于stack exchange，提问作者user87