# 
有一段时间，我在做一个多站点的网页采集项目。目标看起来挺简单的：同时运行一批 Playwright 实例去抓取数据。  
但一开始，我只开了二十几个浏览器，机器就快冒烟了。CPU 一路飙满，内存狂涨，Docker 直接报错退出。那时候我才意识到——**Playwright 真的是吃资源的怪兽**。

于是我开始折腾各种优化手段，从容器拆分、异步控制到代理分流，整整调了一个月，才终于让**100 个浏览器能稳定跑起来，而且一晚上都不崩**。

这篇文章就分享整个过程：从最初的性能瓶颈，到最终压测结果，再到中间的那些关键“拐点”。

## 一、性能瓶颈：为什么 Playwright 跑多了就挂
刚开始的方案其实很“直男”：  
我在一台 8 核 16G 的机器上，用 Python 异步任务批量启动 Playwright 实例。理论上讲，多核机器嘛，几十个浏览器应该轻松搞定。

结果完全相反。

运行到第 20 个实例时，CPU 就快顶不住了。到第 30 个时，Playwright 直接报错 `browser disconnected`，然后容器 OOM（内存溢出），服务挂掉。

我用 `htop` 和 `docker stats` 看了一下资源占用情况：

+ 每个浏览器进程大概吃 150~250MB 内存；
+ CPU 时间主要消耗在页面渲染和网络等待上；
+ Python 主进程成了调度瓶颈。

简单来说，就是**单容器跑太多浏览器，会把系统拖垮**。

## 二、性能基线：没对比就没有改进
在优化之前，我先测了三个关键指标，算是给后面调优做参考。

+ **启动耗时**：平均打开一个浏览器并创建上下文，大约 3.8 秒；
+ **CPU 占用**：在 20 并发下就能吃满 96% 的 CPU；
+ **稳定运行时长**：大约 18 分钟容器就会崩掉。

这三个数字基本说明问题了：**系统既不快，也不稳，更撑不久。**

## 三、优化过程：三板斧搞定
### 1. 容器拆分：别把所有浏览器塞进一个锅
我第一步做的，就是让每个 Docker 容器只跑少量实例。具体来说，一个容器只负责 10 个浏览器。  
这样做有几个好处：

+ 内存压力更分散；
+ 某个容器崩了不会拖垮全局；
+ 可以更灵活地扩容或缩容。

我用 `docker-compose` 启动多个轻量容器，每个容器限制 2 核 CPU、2GB 内存。这样一台 8 核机器就能稳定跑 4<sub>5 组，也就是 40</sub>50 个浏览器实例。如果再开一台机器，就能轻松上百。

这种拆分方式看似简单，其实解决了大部分稳定性问题。

### 2. 网络层优化：用代理把出口分流开
第二个问题是**IP 限制**。  
高并发请求时，目标网站很快就把固定出口 IP 封掉。  
于是我接入了**爬虫代理**，给每个浏览器分配独立代理。

下面是关键代码片段

```python
import asyncio
from playwright.async_api import async_playwright

# ==== 亿牛云爬虫代理配置 ====
PROXY_HOST = "proxy.16yun.cn"   # 代理域名
PROXY_PORT = "3100"            # 代理端口
PROXY_USER = "your_username"    # 用户名
PROXY_PASS = "your_password"    # 密码

TARGET_URL = "https://www.baidu.com"  # 测试目标

async def fetch_page(playwright, index):
    browser = await playwright.chromium.launch(
        proxy={
            "server": f"http://{PROXY_HOST}:{PROXY_PORT}",
            "username": PROXY_USER,
            "password": PROXY_PASS
        },
        headless=True
    )
    context = await browser.new_context()
    page = await context.new_page()

    # 设置 User-Agent 模拟不同设备访问
    await page.set_extra_http_headers({
        "User-Agent": f"Mozilla/5.0 (Windows NT 10.0; Win64; x64) Scraper-{index}"
    })

    try:
        await page.goto(TARGET_URL, timeout=15000)
        title = await page.title()
        print(f"[{index}] OK - {title}")
    except Exception as e:
        print(f"[{index}] Error: {e}")
    finally:
        await browser.close()

async def main():
    async with async_playwright() as p:
        tasks = [fetch_page(p, i) for i in range(1, 11)]  # 每个容器跑10个实例
        await asyncio.gather(*tasks)

if __name__ == "__main__":
    asyncio.run(main())
```

每个浏览器实例都有独立的代理和 User-Agent，这样不仅能防封禁，还能分散请求压力。  
我在实际采集中发现，这个改动直接让失败率从 20% 降到了 2%。

### 3. 异步与延迟启动：不要让 CPU 同时尖叫
原本我是一口气启动所有浏览器任务，这会在几秒钟内拉满 CPU 和内存。  
于是我改成“分批启动”，每隔几百毫秒启动一部分，让系统有喘息空间。

```python
# 延迟分批启动浏览器，避免瞬时峰值
for i in range(0, len(tasks), 5):
    batch = tasks[i:i+5]
    await asyncio.gather(*batch)
    await asyncio.sleep(0.3)
```

这个小改动带来的效果非常明显：CPU 峰值从接近 100% 降到了 70% 左右。  
容器不再频繁重启，整体运行更平稳。

## 四、压测结果：数字不会骗人
经过这三步调整后，我重新做了一轮压测。

**优化前：**

+ 平均启动耗时 3.8 秒
+ CPU 占用接近 100%
+ 内存 15GB 左右
+ 稳定运行不到 20 分钟

**优化后：**

+ 平均启动耗时降到 1.6 秒
+ CPU 占用控制在 75~80%
+ 内存下降到 8~9GB
+ 稳定运行超过 8 小时无异常

这些变化意味着什么？  
意味着我不需要再盯着监控屏幕等崩溃了。容器运行稳定，任务调度更顺畅，爬取速率也稳中有升。

## 五、最终方案：更像一个小型集群
最后我的整体架构变成了一个小型分布式集群：

+ 一个控制器进程负责分配任务和监控状态；
+ 每个 Docker 容器负责一组浏览器实例；
+ 代理服务负责出站流量分流；
+ 所有容器的数据结果汇总回主控制器统一存储。

这种结构最大的优点是**可水平扩展**。  
要采更多网站，只需多开几组容器；要稳定性更高，就调小单容器实例数量。非常灵活。

## 六、经验与反思
回过头看，其实容器化只是解决方案的一部分。  
真正让系统稳定下来的，是三个关键思想：

1. **拆分负载** —— 不要把所有实例塞进同一个进程或容器；
2. **代理隔离** —— 不让所有请求走同一个出口；
3. **分批启动** —— 让系统有呼吸的节奏。

我后来又在别的采集项目上复用了这套方案，效果一样稳。

总结一句话：

> 性能优化的目标，不是让程序更快，而是让它在高负载下还能“活得久”。
>

如果你现在也在调 Playwright 的并发性能，不妨先别想着“多快”，先让它“别挂”。  
从容器拆分、代理分流和异步控制入手，或许就能让你的系统跑得又稳又久。





有一段时间，我在做一个多站点的网页采集项目。目标看起来挺简单的：同时运行一批 Playwright 实例去抓取数据。  但一开始，我只开了二十几个浏览器，机器就快冒烟了。CPU 一路飙满，内存狂涨，Docker 直接报错退出。那时候我才意识到——Playwright 真的是吃资源的怪兽。

容器化 + Playwright：我怎么让 100 个浏览器同时跑还不宕机

本文分享了作者在多站点网页采集项目中使用Playwright遇到的性能瓶颈及优化过程。通过容器拆分、网络层优化和异步控制，成功使100个浏览器实例稳定运行，提升了系统稳定性和爬取效率。最终形成了一个可水平扩展的小型分布式集群架构。作者强调，性能优化的目标是在高负载下保持稳定运行。

编程语言

前端

Playwright多站点采集性能优化实战：从单容器崩溃到100个浏览器稳定运行。通过容器拆分、代理分流和异步控制三板斧，将启动耗时从3.8秒降至1.6秒，CPU占用从100%降到75%，实现8小时稳定运行。分享解决OOM崩溃、IP封禁等关键问题的优化思路。

容器

Docker

Python

Agent

11.11畅享AI算力 云启新增长

域名特惠新用户低至1元！


domain

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

容器化 + Playwright：我怎么让 100 个浏览器同时跑还不宕机-腾讯云开发者社区-腾讯云

容器化 + Playwright：我怎么让 100 个浏览器同时跑还不宕机

容器化 + Playwright：我怎么让 100 个浏览器同时跑还不宕机

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐