CPU heavy load

[abstream]

My cpu(2 core digital ocean, 2GB instance) goes to 15% with just 2 players, I wonder what is going to be with 50 or 100? Do you guys have some real statistics with your hosting? What are the hosting requirements? What kind of a server do I need? How many instances of the server do you run, basically what is your approach in regards of the heavy cpu load?

[abalabahaha]

Performance has been a big issue for a long time now. Nobody's actually tested this clone on a large scale, so there aren't really any numbers or recommended specifications for hosting.

[abstream]

Thanks for your response. Could you point me to the most cpu consuming part of this project, I would like to have a look....Would you say that the Ogra open source server with a custom client(or maybe agar.io client) is doing any better?

[abalabahaha]

agar.io custom clients are not allowed by their ToS I believe. Ogar server, though, has better performance IIRC.

EDIT: Sorry, didn't make it clear. Yeah scratch is fine.

[huytd]

I created a new branch for multi server supporting recently here https://github.com/huytd/agar.io-clone/tree/multi-server hopefully it will help increase the performance and reduce CPU load

[abstream]

@abalabahaha custom clients are fine as long as they are written from scratch, the client in this repository is fine and i saw the agar.io dev to post comments on that.

@huytd thanks about the multi server repo - could you explain really fast how it works and how it helps the cpu load issue?

[mbenatti]

@huytd I Have some doubt than @abstream Quoting him: "@huytd thanks about the multi server repo - could you explain really fast how it works and how it helps the cpu load issue?" Ty so much!

[huytd]

I put some brief explaination in this wiki file, please check it https://github.com/huytd/agar.io-clone/wiki/Multi-server-Experimental

I'm here for any question :D

[underGhost]

I'm gonna look into methods for this as well. I'm sure we can optimize the weaknesses of the game to bring down the cpu usage.

[underGhost]

I was able to remove some of the canvas renderings (since I'm working on the logic for z-index). Viruses are image sprites and the players will be too. The grid was moved to a background image instead of canvas rendering it. People will also be able to customize their backgrounds if they don't want a grid :)

[julianjelfs]

By the way I tried converting from socket.io to ws on my own fork. I did not get as far as using binary protocol, but it did not significantly improve things it seems.

In my environment the problem is that the rendering on the client simply takes too long to fit into the 16ms budget required for smooth (60fps) animation. I think it is likely that the changes made by @underGhost should improve that but I haven't tried it yet.

So I am inclined not PR the socket changes because it's quite disruptive and doesn't really seem to help.

[huytd]

Yeah, the fact is... we have too many for/nested for loops just to render a single object (a piece of food, or a player,...), and this bunch of loops will be called every 1000 / 60 milliseconds...

I think we should thinking how to improve the rendering performance, mostly is, reduce the unnecessary for loops, for example:

• Using an image instead of drawing shapes for foods (the most popular object on the screen)
• Use multiple canvas layers (http://www.ibm.com/developerworks/library/wa-canvashtml5layering/)
• ...

[abalabahaha]

The binary protocol merely makes packets smaller, but doesn't help with CPU that much, so it isn't the biggest issue at hand.

[ghost]

And it also would be faster if we migrate from socket.io to ws

[julianjelfs]

socket.io to ws doesn't make a huge amount of difference by the way. I tried it. Rendering is more of a problem. network might end up being the bottle neck in the end so it could still be worth it though.

[RepComm]

I was reading up on socket.io vs WebSocket and it seems that socket ends up starting with fallback Ajax before upgrading, which causes a lot of waste. In combination with WebSocket, I think several of the fixes you all have mentioned would really clear the engine up. As for binary: It will be more strain on the CPU to parse the data into binary, you might consider storing the data in binary to cut the chase. I know y'all haven't even been here for a year, but I'm interested in taking a poke into the code, and might do the mentioned changes on my own fork.