3 ms·
The demo barely works at all, with sub 100 players, hits won't register, flying is jerky. I get thats is only a demo but its not a very convincing one :/
by peregrine 13y ago
The demo barely works at all, with sub 100 players, hits won't register, flying is jerky.
I get thats is only a demo but its not a very convincing one :/
- pron 13y agoFlying is jerky because we do no client-side processing. A real MMO will use dead-reckoning etc. At the top left of the screen you can see your network latency. Obviously, it depends on where you are. The server is a single US-EAST EC2 instance. So this is entirely a network issue. I can tell you that the server isn't starting to feel the load yet, and is currently running at 32.5Hz (pretty much the maximum rate). This is a much higher rate than most MMOs that run at 4-10Hz.
- banachtarski 13y agoThe server load won't say much about latency. And it's java.
- RyanZAG 13y agoYou're probably correct, but it really isn't very convincing...
- stcredzero 13y agoI have to concur with Ryan, but for slightly different reasons. For me, the biggest scaling concerns are not with efficient use of hardware, but with guaranteeing user experience. I can see how the actor model can ensure efficient use of hardware. I can also see how it could be leveraged to give responses to user input almost as fast as network latency will allow. I'm not yet sure that it will make performance monitoring or understanding performance bottlenecks any easier or that it won't make such activities more complicated.
- pron 13y agoI don't think it will make identifying performance bottlenecks easier, but I can't see why it would make it harder, either. Modern software systems are complicated; they're built on complicated middleware on top of complicated OS, on top of complicated hardware. There are tools to help you find your bottlenecks, but handicapping your application just so you'll understand it as we used to understand performance in the 80s and 90s seems like the wrong choice. If you want to have a simple mental model of your application's performance, just run it on a 386. With instruction-level parallelism, multiple cores with MESI coherence protocols, optimizing JITs, automatic memory management and more, the days of running the code in our head to find problems are long gone. You have to measure with the new tools and learn to trust them.
- stcredzero 13y agoI don't think it will make identifying performance bottlenecks easier, but I can't see why it would make it harder, either. Well, in the example of your demo, the system can detect individual actor-loop overruns. How do I know that this will result in a graceful degradation? What if all of the overruns happen so close together in time, the system has insufficient time to mitigate and keep out of the notice of players? If having game loops on individual actors is more efficient but otherwise semantically equivalent to having a game loop, I would like to know more about this. However, my understanding of the actor model is that it comes with built-in indeterminacy. http://en.wikipedia.org/wiki/Actor_model#Unbounded_nondeterminism_controversy http://en.wikipedia.org/wiki/Actor_model#Unbounded_nondeterm... Modern software systems are complicated; they're built on complicated middleware on top of complicated OS, on top of complicated hardware. There are tools to help you find your bottlenecks, but handicapping your application just so you'll understand it as we used to understand performance in the 80s and 90s seems like the wrong choice. A system one can analyze is always preferable to a system that's potentially more efficient but less understandable. I'm not trying to shoot down your architecture. I considered it for a couple of weeks, but I turned it down because I couldn't understand the risks involved. You can leave this as "an exercise for the reader" but we both understand this isn't going to win most people over. (Maybe that's your goal?)
- pron 13y ago