I think you're right, a VPS is probably what I'm looking for or some kind of VPS / PaaS hybrid. This way I'll know for sure the amount of CPU I can use and my app won't be affected by others app. I'll also go for a modular architecture so it's easier to scale later on.
About the performance, I know there's a lot of ways to optimize what I'm doing, it's almost funny just how unperformant my prototype is right now :) Thanks for the pointers! Le mardi 25 septembre 2012 06:22:59 UTC-4, Rob Ashton a écrit : > > And with a direct answer to the original question, I'd go directly to them > and ask them what kind of systems they're giving you and whether they'll be > able to sustain constant CPU load on the instances you're buying. Again - > if you can work out how many games/users on average bring the CPU up to > your tolerance limits then you can use this as a guide for using their > per-user scaling settings. > > On Tue, Sep 25, 2012 at 12:19 PM, Rob Ashton > <[email protected]<javascript:> > > wrote: > >> I'll second this, but with the knowledge that if you're doing a >> synchronous time-step based simulation and just using the server version of >> this to be the 'master' in decision making then know you can end up with JS >> with 'heavy' CPU use on the server. Providing this CPU is spread out over >> the frames sensibly and doesn't starve the event loop and prevent >> communication this will work fine. >> >> This can be mitigated by as the original author writes, scaling >> horizontal with spawning processes for individual games (or clusters of >> games). >> >> I think you'd be better off running on a VPS directly at this point >> though, working out how many games you can reasonably run and spawning new >> systems when you reach those limits. (Note: Going with a cheap VPS will >> mean you won't be able to keep up a constant use of CPU because they're >> assuming you don't need much and they'll be giving you burst only) >> >> I would like to make a couple of comments at this point though >> >> 1) 60 times a second is too much, I'd suggest bringing that down to >> something reasonable like 2-5 times a second and rubber-banding where >> necessary - this will make you more resilient to latency issues >> 2) Don't worry too much about scaling until you need to, you *should* if >> designed well be able to get away with a single machine for quite a while >> (even if it means beefing up a super amazon EC2 machine) >> 3) Given 1+2, it also sounds a bit like you're trying to run the physics >> at 60fps too, giving you a frame-time of only 16ms - given the environment >> you're running in you might want to bring *that* down to 20fps and tween >> the rest of it. >> >> In essence, what I'm saying here is use some tricks to kill off your >> abuse of the CPU, mitigate latency with those same tricks and you should be >> able to avoid having to worry about multiple servers until you know whether >> it's worth spending time and money on that problem. >> >> Cheers, >> >> Rob >> >> >> >> On Tue, Sep 25, 2012 at 9:23 AM, greelgorke <[email protected]<javascript:> >> > wrote: >> >>> just for interest, why do you use a cpu heave application on node, which >>> is built to serve I/O-heavy application? >>> >>> Am Montag, 24. September 2012 22:21:12 UTC+2 schrieb David: >>> >>>> Hi everyone, >>>> >>>> I'm trying to figure out which PaaS, if any, would suit my project >>>> best. I've been searching and reading a lot but I'm still pretty new to >>>> this and would like your opinion on the subject. >>>> >>>> My project is a physic based multiplayer game. The simulation is run >>>> server side and is controlled by the input of players. About 60 times a >>>> second, it broadcasts all changes to the players that share the same >>>> world. >>>> Each world is run independently and accepts between 4 and 8 players. >>>> >>>> Right now, my prototype isn't optimized at all but I can already see >>>> that I'll need to horizontally scale it at some point, so I'm trying to >>>> figure out how it's going to be done. >>>> >>>> I understand I could do it on an IaaS like Joyent but I would like to >>>> see if there's a PaaS out there that would simplify my work. >>>> >>>> Here are the requirements for the project: >>>> >>>> 1) While the number of concurrent connections might be low, the CPU >>>> usage can be high, the solution needs to scale not only on the amount of >>>> concurrent connections but also on the amount of CPU used. For example, >>>> correct me if I'm wrong but I believe Nodejitsu only scales based on >>>> concurrent request and hence isn't suited for CPU heavy app. The >>>> application would just slows down and never scale because it doesn't reach >>>> a specific concurrent connection threshold. >>>> >>>> 2) Low latency is also very important, this isn't a farm game, it's a >>>> physic simulation with moving objects. At 50ms, my prototype plays really >>>> smoothly but past 100-150ms, the experience starts to suffer. I need to be >>>> able to make sure it stays low or act accordingly when it gets high. >>>> >>>> 3) The server sends a lot more data than it receives, so I expect this >>>> could also be a bottleneck. >>>> >>>> That's basically it, any advice, pointers, tips are welcome. >>>> >>>> Thanks in advance. >>>> >>>> -- >>> Job Board: http://jobs.nodejs.org/ >>> Posting guidelines: >>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To post to this group, send email to [email protected]<javascript:> >>> To unsubscribe from this group, send email to >>> [email protected] <javascript:> >>> For more options, visit this group at >>> http://groups.google.com/group/nodejs?hl=en?hl=en >>> >> >> > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
