【发布时间】：2012-06-20 00:21:44
【问题描述】：
我正在使用 MongoDB 测试 Node.js 的性能。我知道这些中的每一个都很好，彼此独立，但我正在尝试一些测试来感受它们。我遇到了这个问题，我无法确定来源。
问题
我正在尝试在单个 Node.js 程序中插入 1,000,000 条记录。 它绝对会爬。我们说的是 20 分钟的执行时间。无论是我的 Mac 还是 CentOS，都会发生这种情况，尽管两者的行为略有不同。它最终会完成。
效果类似于交换，但不是（内存永远不会超过 2 GB）。 MongoDB 只打开了 3 个连接，而且大多数时候没有插入数据。它似乎做了很多上下文切换，并且 Node.js CPU 内核已被最大化。
效果与this thread中提到的类似。
我尝试使用 PHP 进行相同的操作，它会在 2-3 分钟内完成。没有剧情。
为什么？
可能的原因
我目前认为这要么是 Node.js 套接字问题，要么是 libev 在幕后发生的事情，要么是其他一些 node-mongodb-native 问题。我可能完全错了，所以我在这里寻求一些指导。
至于其他 Node.js MongoDB 适配器，我尝试过蒙古语，它似乎对文档进行排队以便批量插入它们，但最终内存不足。所以就这样了。 （旁注：我也不知道为什么会这样，因为它甚至没有接近我的 16 GB 盒子限制——但我没有费心对此进行进一步调查。）
我应该提一下，实际上我确实测试了一个有 4 个工作器的主/工作器集群（在四核机器上），它在 2-3 分钟内完成。
守则
这是我的 Node.js CoffeeScript 程序：
mongodb = require "mongodb"
microtime = require "microtime"
crypto = require "crypto"
times = 1000000
server = new mongodb.Server "127.0.0.1", 27017
db = mongodb.Db "test", server
db.open (error, client) ->
throw error if error?
collection = mongodb.Collection client, "foo"
for i in [0...times]
console.log "Inserting #{i}..." if i % 100000 == 0
hash = crypto.createHash "sha1"
hash.update "" + microtime.now() + (Math.random() * 255 | 0)
key = hash.digest "hex"
doc =
key: key,
foo1: 1000,
foo2: 1000,
foo3: 1000,
bar1: 2000,
bar2: 2000,
bar3: 2000,
baz1: 3000,
baz2: 3000,
baz3: 3000
collection.insert doc, safe: true, (error, response) ->
console.log error.message if error
这是大致等效的 PHP 程序：
<?php
$mongo = new Mongo();
$collection = $mongo->test->foo;
$times = 1000000;
for ($i = 0; $i < $times; $i++) {
if ($i % 100000 == 0) {
print "Inserting $i...\n";
}
$doc = array(
"key" => sha1(microtime(true) + rand(0, 255)),
"foo1" => 1000,
"foo2" => 1000,
"foo3" => 1000,
"bar1" => 2000,
"bar2" => 2000,
"bar3" => 2000,
"baz1" => 3000,
"baz2" => 3000,
"baz3" => 3000
);
try {
$collection->insert($doc, array("safe" => true));
} catch (MongoCursorException $e) {
print $e->getMessage() . "\n";
}
}
【问题讨论】：
-
好吧，说句公道话，你并不真正了解我的用例。这只是一个测试，几个测试之一。我遇到了一个有趣的结果，想知道它是否适用于整个 Node.js 或这个特定模块。无论哪种方式，理解原因有助于我更好地理解如何更有效地使用 Node.js 和/或这个模块。 :-)
-
没错，这也可以是客户端库。
-
如果 node.js CPU 内核已经用完，你是不是已经发现了问题。任何基于 JS 的单进程应用程序服务器都不会达到接近最大吞吐量的任何目标。如果你在同一个盒子上启动多个 node.js 进程会发生什么？老实说，我完全不明白为什么 node.js 会因为这些原因而在 Web 应用程序开发领域的更专业端获得任何牵引力，但是嘿。
-
问题是为什么单线程 PHP 进程优于单线程 Node.js 进程（当然，对于使用 node- mongodb-native 适配器。固定的 CPU 只是问题的一个症状。我应该提一下，我确实测试了一个有 4 个工作人员（在四核机器上）的主/工作集群，它在 3 分钟内完成。
-
这就是我的怀疑。我的单个进程爬网是因为 Node 在后台启动了许多事件线程，并反复轮询它们以查看哪些完成。幕后轮询的成本导致其速度急剧下降。随着回调数量的增加，执行时间似乎以对数方式增加。
标签： php performance node.js mongodb