我们正在考虑使用 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 和复制，但我想尝试以类似于 Siege 可以对具有多个 Assets 的页面进行压力测试的方式编写脚本。只是，我希望它“等待”，直到页面真正完成并且所有 JS 完成运行。
知道如何做到这一点吗？
最佳答案
听起来您正在尝试通过模拟您期望从用户那里收到的负载来对整个系统进行压力测试，即您并不是在尝试测试浏览器性能本身。 (如果情况并非如此，并且您尝试在浏览器中进行测试，那么我们已经有一些 browser performance tests in PouchDB ，尽管您会从 PhantomJS 得到错误的数字，因为它是旧浏览器。)
由于 PouchDB 是同构的，我建议避免使用 PhantomJS，而只在 LevelDB 之上运行一些 Node.js 进程来模拟您的用户。 PhantomJS 确实可能存在一些排队问题，因为底层数据存储是 WebSQL，它具有全局写锁。不过，使用 Node，您可以拥有单独的进程，每个进程代表一个线程；您只需确保每个数据库都有一个单独的 LevelDB，因为 LevelDB 不是线程安全的(例如 new PouchDB('/tmp/some/random/directory'))。
关于javascript - 如何对 PouchDB 进行压力测试，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27639211/