Console.log is sync

[majimboo]

Console.log() will kill performance, if you must log on actual deployment do write on a file. Or use Winston.js a multi transport logging tool. You can set whether to log it to a file or a console. This way you can easily change it depending on production and development.

[LiamKarlMitchell]

Yes I have heard similar things and was actually thinking about mongojs vs file vs redis for logging. There are some nice tools to view logs and use elasticsearch. I will look at Winston.js too :)

Although I would think in node.js that a console.log() would be async? How would it kill performance?

From stack overflow: http://stackoverflow.com/questions/7566517/difference-in-blocking-between-sys-log-and-console-log-and-console-error

console.error is blocking (it calls sync write in writeError
<https://github.com/joyent/node/blob/master/src/node_stdio.cc#L167>).

console.log is non-blocking = process.stdout.write(util.format.apply(this,
arguments) + '\n'); ```` It would not make sense for me for node.js to
destroy its model/performance with such a common to use command. No doubt
there is a thread to handle IO with the operating system window/terminal.
It would be silly to make it block. An error blocking is understandable as
there is more information and it wants it to write in a block but that
could be re-written to async it in one go. Although the problem is if the
error is then going to close the server it may never get written out if it
blocks and does not wait. So it could be by design?.

On Tue, Jul 1, 2014 at 5:06 AM, Majid Arif Siddiqui <
notifications@github.com> wrote:

> Console.log() will kill performance, if you must log on actual deployment
> do write on a file. Or use Winston.js a multi transport logging tool. You
> can set whether to log it to a file or a console. This way you can easily
> change it depending on production and development.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/LiamKarlMitchell/InfiniteSky/issues/90>.
>

[LiamKarlMitchell]

A better logging system is on list of things I want to do :).

On Tue, Jul 1, 2014 at 12:24 PM, Liam Mitchell liamkarlmitchell@gmail.com wrote:

Yes I have heard similar things and was actually thinking about mongojs vs file vs redis for logging. There are some nice tools to view logs and use elasticsearch. I will look at Winston.js too :)

Although I would think in node.js that a console.log() would be async? How would it kill performance?

From stack overflow: http://stackoverflow.com/questions/7566517/difference-in-blocking-between-sys-log-and-console-log-and-console-error

console.error is blocking (it calls sync write in writeError
<https://github.com/joyent/node/blob/master/src/node_stdio.cc#L167>).

console.log is non-blocking = process.stdout.write(util.format.apply(this,
arguments) + '\n'); ```` It would not make sense for me for node.js to
destroy its model/performance with such a common to use command. No doubt
there is a thread to handle IO with the operating system window/terminal.
It would be silly to make it block. An error blocking is understandable as
there is more information and it wants it to write in a block but that
could be re-written to async it in one go. Although the problem is if the
error is then going to close the server it may never get written out if it
blocks and does not wait. So it could be by design?.

On Tue, Jul 1, 2014 at 5:06 AM, Majid Arif Siddiqui <
notifications@github.com> wrote:

> Console.log() will kill performance, if you must log on actual deployment
> do write on a file. Or use Winston.js a multi transport logging tool. You
> can set whether to log it to a file or a console. This way you can easily
> change it depending on production and development.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/LiamKarlMitchell/InfiniteSky/issues/90>.
>

[majimboo]

Actually if you have a lot of task, let us say 1000 packets coming in per minute. The basic principle of Node.JS is you can only do one thing at a time, so do it fast.

Console.log is mainly javascript and is pretty much sync. It will write to the console and block, and keep writing until it is done then continue the process.

You'll notice this when you'll start to get more traffic. Trust me I have been emulating a game server for an MMORPG in Node.JS for awhile. I saw your repo because I was searching for ways to handle packets as I was trying to replace my current implementation, that is when I saw restruct, but it doesn't seem to support null-terminated strings, which is something I need.

So one emu dev to another, just sharing things I learned the hard way.

[LiamKarlMitchell]

Ah thanks for sharing, although what I saw was that it is async you might be right I have not looked at its internal code yet lol.

Would you mind sharing your project/repo with me to look at as well maybe we can learn from each other? :D

Add me on skype if you like/have it, mb10241 and the restruct I am using definatly handles null terminated string as you can see in my reply to that issue.

On Tue, Jul 1, 2014 at 2:21 PM, Majid Arif Siddiqui < notifications@github.com> wrote:

Actually if you have a lot of task, let us say 1000 packets coming in per minute. The basic principle of Node.JS is you can only do one thing at a time, so do it fast.

Console.log is mainly javascript and is pretty much sync. It will write to the console and block, and keep writing until it is done then continue the process.

You'll notice this when you'll start to get more traffic. Trust me I have been emulating a game server for an MMORPG in Node.JS for awhile. I saw your repo because I was searching for ways to handle packets as I was trying to replace my current implementation, that is when I saw restruct, but it doesn't seem to support null-terminated strings, which is something I need.

So one emu dev to another, just sharing things I learned the hard way.

— Reply to this email directly or view it on GitHub https://github.com/LiamKarlMitchell/InfiniteSky/issues/90#issuecomment-47610289 .

[majimboo]

I'm actually not pushing actual source-code to any (public) repo because the game I'm emulating for doesn't have any publicly released code and there are currently no private server.

But I have recently been pushing a few things into a repo (related to the game emu), just experimental codes, things I'm trying out. It is called Khanton, you can check it on my repos.

Learning from each other would be great :) I'm currently more active on the experimental code than the actual development as I am trying to find other ways so I could squeeze out more performance.

[LiamKarlMitchell]

Sure, thats understandable :P This game does not have any released code either and has only 1 server in Korea.

It is a difficult and long task hopefully you have a good team/community. :).

On Tue, Jul 1, 2014 at 2:30 PM, Majid Arif Siddiqui < notifications@github.com> wrote:

I'm actually not pushing actual source-code to any (public) repo because the game I'm emulating for doesn't have any publicly released code and there are currently no private server.

But I have recently been pushing a few things into a repo (related to the game emu), just experimental codes, things I'm trying out. It is called Khanton, you can check it on my repos.

— Reply to this email directly or view it on GitHub https://github.com/LiamKarlMitchell/InfiniteSky/issues/90#issuecomment-47610666 .

[majimboo]

Oh, I thought I saw a 12Sky released servers on ragezone but I haven't been there for a long time. But doing this is actually cool. Maybe I'll push the real sources out soon but currently I have not planned that. Also I'm working on it alone, only on my free time as there is also a lot to do at work.

We can continue this on Skype though. You may close all my open tickets.