[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","root",{"_11":-5},"routes/user.$name.collections",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":16},"topics",[35],"user",{"_20":21,"_13":14,"_22":23,"_24":14,"_25":26,"_27":28,"_29":30,"_31":32,"_33":34},"loginname","kidyfirst","page",1,"limit",20,"total","id","18705","avatar_url","https://avatars2.githubusercontent.com/u/2074642?v=3","githubUsername","create_at","2015-09-11 10:33:31.115","score",35,"topic_count",4,"reply_count",3,"is_star",false,{"_20":36,"_37":38,"_39":-5,"_40":41,"_42":43,"_44":45,"_46":34,"_47":34,"_31":48,"_49":50,"_25":51,"_52":53},"2299","author_id","6127","tab","content","我在做长连接服务器的时候遇到些问题，[stackoverflow链接](http://stackoverflow.com/questions/14049109/long-connections-with-node-js-how-to-reduce-memory-usage-and-prevent-memory-lea)\r\n\r\n现在平均下来每个连接占12k多的内存，感觉还不是很理想（希望降到8k以下），谁能指点下(linux内核调优方面和node.js代码方面等)? 谢谢！\r\n\r\n另外搜集资料的时候，发现这种场景以下几种技术用得也比较多：c/c++（libev,libeio）（当然node.js底层也是他们），Java NIO，erlang，有哪位大神做过得，可否分享下经验？相比起来，哪种更有优势？或者谁对这几种方案比较熟悉，做个demo来跟node.js比一下？\r\n\r\n**2013-1-8**：\r\n做了以下测试，发现一些奇怪的现象：\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n

序号	并发量（万）	free -m(used -buffers/cache)	node.js RSS	描述
1	6	500	210	无sendResonse，无cacheSocket
2	6	578	290	无sendResonse，有cacheSocket
3	6	822	290	有sendResonse，有cacheSocket

\r\n\r\nsendResonse，cacheSocket见下面代码：\r\n\r\n var net = require('net');\r\n \r\n var pendingClients = {};\r\n var clientsCount = 0;\r\n \r\n var server = net.createServer(function (socket) {\r\n var buffer = '';\r\n socket.setEncoding('utf-8');\r\n socket.on('data', onData);\r\n \r\n function onData(chunk) {\r\n buffer += chunk;\r\n // Parse request data.\r\n // ...\r\n \r\n if ('I have got all I need') {\r\n socket.removeListener('data', onData);\r\n \r\n // Doing this to provide the same interface with official http module\r\n var req = {\r\n clientId: 'whatever'\r\n };\r\n var res = new ServerResponse(socket);\r\n server.emit('request', req, res);\r\n }\r\n }\r\n });\r\n \r\n server.on('request', function (req, res) {\r\n // Other business logic\r\n // ...\r\n \r\n clientsCount++\r\n console.log(clientsCount);\r\n \r\n sendResponse(res);\r\n cacheSocket(req, res);\r\n });\r\n \r\n server.listen(3000);\r\n \r\n // Custom ServerResponse\r\n function ServerResponse(socket) {\r\n this.socket = socket;\r\n }\r\n ServerResponse.prototype.write = function(data) {\r\n if (this._headerSent) {\r\n // Send http header\r\n // ...\r\n \r\n this._headerSent = true;\r\n }\r\n \r\n // Parse data to 'Transfer-Encoding: chunked'\r\n // ...\r\n \r\n this.socket.write(data);\r\n }\r\n \r\n function sendResponse(res) {\r\n res.write('PING');\r\n }\r\n \r\n function cacheSocket(req, res) {\r\n pendingClients[req.clientId] = {\r\n res: res\r\n };\r\n \r\n res.socket.on('error', function (err) {\r\n console.log(err);\r\n });\r\n \r\n res.socket.on('close', function () {\r\n delete pendingClients[req.clientId];\r\n \r\n clientsCount--;\r\n });\r\n }\r\n\r\n问题：\r\n* 3和2相比，RSS不变，也就是说用于内核TCP栈的内存多了200多M，平均每个连接多了接近4k，我怀疑是内核socket的send buffer，但是调整**net.ipv4.tcp_wmem**不起作用？如果是send buffer，为何发送响应之前没有出现，难道是只有发送数据时才开辟吗？网上实在是找不到资料能解释这个问题了……\r\n* 2和1相比，不缓存node.js生成的socket对象，省了80M左右，我打算采用[@codekiller](/user/codekiller)的建议，直接操作handle，肯看效果怎么样，后面会把结果放上来\r\n* 还有一个十分诡异的问题，关于**net.ipv4.tcp_mem**。当该值设置为：**48120 64161 96240**（单位是page，一个page4KB，刚好是tcp_wmem和tcp_rmem的最小值）（Ubuntu12.04默认值）时，采用第一种测试方法，最多只能压进96238个并发连接，再多一个，整个server的tcp连接都会停止响应，ssh都连不进去，这肯定跟**net.ipv4.tcp_mem**的最大值**96240**有关，但是**sendResponse**时，却没有这个问题，实在想不通，何解？\r\n\r\n**2013-1-12**\r\n采用[@codekiller](/user/codekiller)的建议后，直接使用handle，每6万连接大概省下100M内存，在此表示感谢！\r\n\r\n但是对TCP socket的receive buffer和send buffer还是没弄明白，如何进一步优化？以及上面的诡异现象是什么原因？\r\n\r\n最近打算看一下底层的libuv，因为感觉javascript层面已经没什么可做的了，希望能从底层找到突破口（比如直接设置socket的buffer值，现在好像没有这个接口，看看自己能不能加上）\r\n\r\n欢迎大家发表意见，谢谢！\r\n","title","node.js长连接高并发问题，很有挑战，大家来讨论下","last_reply_at","2014-07-23 05:08:05.377","good","top",25,"visit_count",65780,"2013-01-03 14:05:01.758","author",{"_13":54,"_22":55},"inetfuture","http://www.gravatar.com/avatar/0893f12ed69264db6f7a0e81eb82ef2c?size=48"]