如何对 PouchDB 进行压力测试

How to stress test PouchDB

本文关键字：压力测试 PouchDB 更新时间：2023-09-26

我们正在考虑使用CouchDB和PouchDB堆栈，我们希望对CouchDB进行压力测试，因为我们的一个用例可以同时复制多达70-80个用户。

我们设法对CouchDB进行了压力测试，并对结果感到满意，但我们想从PouchDB进行一些端到端的压力测试。

我尝试了几件事：

1）使用 PhantomJS 脚本在 for 循环中启动许多页面2）使用PhantomJS脚本，该脚本具有Github上的某种并行函数3）使用bash脚本和&启动多个phantomJS。4）使用bash脚本和GNU Parallel启动PhantomJS的多个实例* 上面的所有测试都使用 waitFor 函数，仅在全局变量设置为 true 时才完成（我能想到的唯一方法是等待页面中的所有 JS 执行）

虽然一个 phantomJS 执行大约需要 200-300 毫秒，但当运行多个时，它们似乎以某种方式排队，并且我们得到 ~30 次执行中最后一次从 200 毫秒到 30，000 毫秒的数字。

看起来 PhantomJS 以某种方式排队。正如我所看到的每个后续请求的 n*200ms 的稳定进展。

我可能会在 2-3 台设备上构建一个演示应用程序并循环 PUT 和 Replica，但我想尝试以类似于 Siege 可以对具有多个资产的页面进行压力测试的方式编写脚本。只是，我希望它"等待"，直到页面真正完成并且所有 JS 都已完成运行。

知道我该怎么做吗？

听起来您正在尝试通过模拟您希望从用户那里收到的负载来对整个系统进行压力测试，即您没有尝试测试浏览器性能本身。（如果不是这种情况，并且您正在尝试在浏览器中进行测试，那么我们已经在 PouchDB 中进行了一些浏览器性能测试，尽管您会从 PhantomJS 获得错误的数字，因为它是一个旧浏览器。

由于 PouchDB 是同构的，我建议避免使用 PhantomJS，而只是在 LevelDB 上运行一些 Node.js 进程来模拟您的用户。PhantomJS可能确实存在一些排队问题，因为底层数据存储是WebSQL，它具有全局写锁定。但是，使用 Node，您可以拥有单独的进程，每个进程代表一个线程;你只需要确保每个都有一个单独的LevelDB，因为LevelDB不是线程安全的（例如 new PouchDB('/tmp/some/random/directory') ）。