Simulating max clients on a server

#21

Quote:
The server handled 300 AI Players perfectly fine, but was unable to handle more than 100 real clients. The physical network should be able to handle the traffic and messages, so it seems like Torque doesn't like all the network connections? Perhaps my clients are connecting too fast? Any thoughts?

Two reasons:

1. AIPlayers do not tick as often as regular Players that have a GameConnection associated with them.
2. Remember, AIPlayers are connectionless. They have no controlling client to relay packets and their checksums to, and they do not receive ghosting updates which is a huge deal with so many clients.

#22 Well it appears my server "dies" because of collision detection.
I reduced my world to a single big DTS shape with 442 polys, spawned 500 AIPlayer bots that ran around and collided with my shape. CPU utilization went up to 100%, and the server simulation virtually halted.
Then I used a dif shape (the cathedral that came with Constructor), that's more complex than my simple 442 poly DTS shape and the CPU utilization was close but didn't constantly stay at 100%, and the server simulation wasn't as slow and unresponsive as before.

So this leads me to believe that something's wrong with my DTS shape, so I'll have to take a look at why that is. All the collision meshes are convex, so I don't know what else could be wrong.

I also did a test with an empty world. My server breaks at 147 players with each client sending a command every 3-5 seconds. Without sending any commands (commandToServer), my server breaks at 192 players. Note that no objects are being ghosted to these clients, so they are very similar to AIPlayers. So, commandToServer does have an impact, and probably flooded my server with messages. However, without commandToServer, the number of players my server can support in an empty world still seems very low. I was hoping it would at least support 200-300. Any ideas?

Thanks.

#23 Interesting.

DIFs are inherently faster for bulk collisions that DTSs. That's why they exist. So your DTS is probably configured fine. DTS collisions are traditionally only used for detail objects like a tree or a lamp, rather than the bulk of collisions.

By 'empty' you mean just terrain ?
I would expect terrain to be pretty fast at collisions, but it might be interesting to try a world with no terrain and just a DIF.

Quote:Note that no objects are being ghosted to these clients

well except the other 146 or 191 players.

couple thoughts - somewhere there's a thread or resource about increasing the amount of data sent out in each UDP packet. apparently TGE has quite a bit of padding in there to account for various network configurations like PPPoE etc, and can be trimmed. I'll try to find it but a search might be quicker.

also, try reducing the cell size. cells are an invisible grid overlaying the world which are used to optimize collision calculations. i think the default cell size is like 64 units. if your whole world is only the size of say the Ork Village, a more appropriate size might be something much smaller, like 8 or maybe even 4.

#24 Hmm..
What is a "VisibleDistance" in your mission? If ALL 146 (191) players are in the range - then all of them are ghosted to each other - that's huge amount of data to process.

Try to spread all of your players around the whole area (may be even to cover multiple tiles of terrain) and set visibility to something like 200-300 meters.

In our project we had about 30-40 players in the same area at once, most of player was exploring the "world" (it's terrain with squareSize=16 surrounded with mountains and ocean).

#25 The players shouldn't be ghosted to each other if I never call activitateGhosting for the client connection, right?

#26 Right.

#27 I'm unfamiliar with activateGhosting() - does that activate *all* ghosting for the given client ?
Why wouldn't you enable ghosting tho ? Ghosting is how you're able to see other players.

As i understand the word, ghosting means any time client A sees player B, player B has been ghosted to client A. .. Which i presume is the situation you're interested in load-testing.

#28 Thanks Stefan - So none of my clients should be receiving any ghost updates for anything in the world. So, I'm still a bit puzzled why I can only go up to 192 clients in an empty world (only terrain). I'll use Torque's profiler and see if that gives me any insights.

#29 @Orion - I didn't activate ghosting because my sim clients would crash when ghosting was activated. Since graphics was not initialized, I assume they were trying to load the models associated with the other players and the world.

#30 I see. but that seems like a sort of unrealistic test, doesn't it ?
i think a significant part of server load is determining who is in network scope of whom and preparing the ghost updates.

#31 Igor: you can try to assign cameraObject to the client instead of player for testing how many connections torque can handle. There is no collision-related stuff in there IIRC...

Or you can simply do not assign anything at all to the clients :)

#32 I've noticed that Flyingvehicle collisions can also bring the server to a halt with not that many ships. For such a huge amount of players I would suggest you simplifying the collision code.

#33 @James - how would you suggest simplifying the player collision code? I require all the physics functionality Torque offers, and I can't think of anything I can remove to simplify collision.

#34 If you look at all major MMO games you would see they dont really have accurate collision. Now you have to take in mind what type of game you're planning on. You're going to have to decide where to draw the line and sacrifice the player limit or sacrifice accurate percise collisions. You should ask the more adept people on the forums, but I believe the reason you dont see the other games out there currently on the market with such huge player limits is because of this fact. The other is things is, what if all 300 clients decide to get all in one screen (view)... That is just going to kill your framerate, no matter what systems they (or your server) has.

But for your exercise I would start looking at removing collision impacts. Do you really want the impact of 2 objects (Players) to have an effect on each other... Is it really THAT important?... If no.... remove ResolveCollisions, or when objects collide, simplify by just making them stop. Then you can think of removing resolveContacts too, if you need some more CPU cycles.

Or to start of easy just play with the integration of objects in script.

I'm hope someone with more experience could give some input on this too.