We can see that, node.js response time increased with concurrent
connections, any one can explain this?
And how to avoid this problem, and if it is not http but tcp, will it be an
critical issue for multi player online game server, there will be many
concurrent connections.
> We can see that, node.js response time increased with concurrent > connections, any one can explain this?
> And how to avoid this problem, and if it is not http but tcp, will it be > an critical issue for multi player online game server, there will be many > concurrent connections.
> We can see that, node.js response time increased with concurrent
> connections, any one can explain this?
> And how to avoid this problem, and if it is not http but tcp, will it be
> an critical issue for multi player online game server, there will be many
> concurrent connections.
>> We can see that, node.js response time increased with concurrent
>> connections, any one can explain this?
>> And how to avoid this problem, and if it is not http but tcp, will it be
>> an critical issue for multi player online game server, there will be many
>> concurrent connections.
> We can see that, node.js response time increased with concurrent
> connections, any one can explain this?
> And how to avoid this problem, and if it is not http but tcp, will it be an
> critical issue for multi player online game server, there will be many
> concurrent connections.
Your post omits crucial details, like on what OS you tested it, on
what kind of network, with what tool, what the tool's settings were,
etc.
All one can say by the numbers posted is that the response time seems
to scale linearly - which isn't all that bad, really.
this is normal because you are running with default 1024 open file limit.
As the socket pool is limited to 1024 sockets, and you have 1000 concurrent
requests, requests will be accumulated in the socket queue and thus, have
to wait unitl other requests are done from the pool and released.
easy way is to change the /etc/security/limits.conf file and increase the
open file soft/hard limit. Once you increase that, you will be fine with
1000 concurrent requests.
but there are other factors and will overwrite the limit. please see my
website for tips... murvinlai.com
On Thu, Aug 23, 2012 at 3:51 AM, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
> On Thu, Aug 23, 2012 at 7:34 AM, jason.桂林 <guil...@gmail.com> wrote:
> > test by node.js http helloworld
> > We can see that, node.js response time increased with concurrent
> > connections, any one can explain this?
> > And how to avoid this problem, and if it is not http but tcp, will it be
> an
> > critical issue for multi player online game server, there will be many
> > concurrent connections.
> Your post omits crucial details, like on what OS you tested it, on
> what kind of network, with what tool, what the tool's settings were,
> etc.
> All one can say by the numbers posted is that the response time seems
> to scale linearly - which isn't all that bad, really.
This is not a correct response. If you hit the open file limit usually node
will crash (unless you protect against that). It won't ever slow down
because of it. And it won't ever just pause connections until the limit is
lowered. It will throw an error or an exception.
On Thu, Aug 23, 2012 at 8:58 PM, Murvin Lai <murvin...@gmail.com> wrote:
> this is normal because you are running with default 1024 open file limit.
> As the socket pool is limited to 1024 sockets, and you have 1000
> concurrent requests, requests will be accumulated in the socket queue and
> thus, have to wait unitl other requests are done from the pool and released.
> easy way is to change the /etc/security/limits.conf file and increase the
> open file soft/hard limit. Once you increase that, you will be fine with
> 1000 concurrent requests.
> but there are other factors and will overwrite the limit. please see my
> website for tips... murvinlai.com
> On Thu, Aug 23, 2012 at 3:51 AM, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
>> On Thu, Aug 23, 2012 at 7:34 AM, jason.桂林 <guil...@gmail.com> wrote:
>> > test by node.js http helloworld
>> > We can see that, node.js response time increased with concurrent
>> > connections, any one can explain this?
>> > And how to avoid this problem, and if it is not http but tcp, will it
>> be an
>> > critical issue for multi player online game server, there will be many
>> > concurrent connections.
>> Your post omits crucial details, like on what OS you tested it, on
>> what kind of network, with what tool, what the tool's settings were,
>> etc.
>> All one can say by the numbers posted is that the response time seems
>> to scale linearly - which isn't all that bad, really.
> This is not a correct response. If you hit the open file limit usually node will crash (unless you protect against that). It won't ever slow down because of it. And it won't ever just pause connections until the limit is lowered. It will throw an error or an exception.
> On Thu, Aug 23, 2012 at 8:58 PM, Murvin Lai <murvin...@gmail.com> wrote:
> this is normal because you are running with default 1024 open file limit.
> As the socket pool is limited to 1024 sockets, and you have 1000 concurrent requests, requests will be accumulated in the socket queue and thus, have to wait unitl other requests are done from the pool and released.
> easy way is to change the /etc/security/limits.conf file and increase the open file soft/hard limit. Once you increase that, you will be fine with 1000 concurrent requests.
> but there are other factors and will overwrite the limit. please see my website for tips... murvinlai.com
> On Thu, Aug 23, 2012 at 3:51 AM, Ben Noordhuis <i...@bnoordhuis.nl> wrote:
> On Thu, Aug 23, 2012 at 7:34 AM, jason.桂林 <guil...@gmail.com> wrote:
> > test by node.js http helloworld
> > We can see that, node.js response time increased with concurrent
> > connections, any one can explain this?
> > And how to avoid this problem, and if it is not http but tcp, will it be an
> > critical issue for multi player online game server, there will be many
> > concurrent connections.
> Your post omits crucial details, like on what OS you tested it, on
> what kind of network, with what tool, what the tool's settings were,
> etc.
> All one can say by the numbers posted is that the response time seems
> to scale linearly - which isn't all that bad, really.
On Thu, Aug 23, 2012 at 11:30 PM, 桂林 <guil...@gmail.com> wrote:
> Anyone argue with this can make a test on it.
> I am test on MacOSX, benchmark tool is write in node.js.
> 在 2012-8-24，上午11:25， Matt 写道：
> This is not a correct response. If you hit the open file limit usually
> node will crash (unless you protect against that). It won't ever slow down
> because of it. And it won't ever just pause connections until the limit is
> lowered. It will throw an error or an exception.
> On Thu, Aug 23, 2012 at 8:58 PM, Murvin Lai <murvin...@gmail.com> wrote:
>> this is normal because you are running with default 1024 open file limit.
>> As the socket pool is limited to 1024 sockets, and you have 1000
>> concurrent requests, requests will be accumulated in the socket queue and
>> thus, have to wait unitl other requests are done from the pool and released.
>> easy way is to change the /etc/security/limits.conf file and increase the
>> open file soft/hard limit. Once you increase that, you will be fine with
>> 1000 concurrent requests.
>> but there are other factors and will overwrite the limit. please see my
>> website for tips... murvinlai.com
>> On Thu, Aug 23, 2012 at 3:51 AM, Ben Noordhuis <i...@bnoordhuis.nl>wrote:
>>> On Thu, Aug 23, 2012 at 7:34 AM, jason.桂林 <guil...@gmail.com> wrote:
>>> > test by node.js http helloworld
>>> > We can see that, node.js response time increased with concurrent
>>> > connections, any one can explain this?
>>> > And how to avoid this problem, and if it is not http but tcp, will it
>>> be an
>>> > critical issue for multi player online game server, there will be many
>>> > concurrent connections.
>>> Your post omits crucial details, like on what OS you tested it, on
>>> what kind of network, with what tool, what the tool's settings were,
>>> etc.
>>> All one can say by the numbers posted is that the response time seems
>>> to scale linearly - which isn't all that bad, really.
> We can see that, node.js response time increased with concurrent > connections, any one can explain this?
> And how to avoid this problem, and if it is not http but tcp, will it be > an critical issue for multi player online game server, there will be many > concurrent connections.
I'm not arguing or anything, but that's what I observed and recorded during
load testing. Not just once but load testing over weeks, conducted by not
just me but a whole team of developers.
Node.js itself will not crash if hitting open file limit, but some sockets
will hang up, and response get slower, etc.
No matter what, one of the solutions is to increase the open file to
...e.g. over 10K. then you will be safe in most cases.
On Sun, Aug 26, 2012 at 7:09 PM, darcy <freeda...@gmail.com> wrote:
> if your server has reach the cpu upper limit(cpu idle approach 0%) with n
> clients, then the response time will increase with the client number linear.
> On Thursday, August 23, 2012 1:34:31 PM UTC+8, Jason.桂林(Gui Lin) wrote:
>> We can see that, node.js response time increased with concurrent
>> connections, any one can explain this?
>> And how to avoid this problem, and if it is not http but tcp, will it be
>> an critical issue for multi player online game server, there will be many
>> concurrent connections.
