search

owenashurst / agar.io-clone

Agar.io clone written with Socket.IO and HTML5 canvas
MIT License
2.89k stars 1.13k forks source link

CPU heavy load #349

Open abstream opened 8 years ago

abstream commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

abalabahaha commented 8 years ago

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 commented 8 years ago

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

julianjelfs commented 8 years ago

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 commented 7 years ago

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.