When to change thread pool settings?

[ApolloMeijer]

Hey guys!

We have a few issues recently with the amount of time it takes for the smartfox extension to complete a https call to our API.
I am wonderign in what case it would be wise to increase the threads in our server settings?
We have a round 2500 concurrent active users playing.

We are calling these api request from a scheduler we take out of the sfs pool like this.
sfs.getTaskScheduler().scheduleAtFixedRate(taskStatsUpdater, 1000, 20, TimeUnit.MILLISECONDS);

thanks!

[Lapo]

Hi,
before I can help I need a few info:

- how many HTTP calls are you (roughly) running at once?
- is there a specific reason why you delegate the HTTP call to the Scheduler instead of letting the Extension thread do it?
- what version of SFS2X are you using?

thanks

[ApolloMeijer]

Hey Lapo!

We use version 2.10.0

We do not delegate the API calls to the thread on this scheduler but the update of our game runs on this scheduler and in this update we do the API requests. For each room we create the scheduler for the update function and only do one API call at once in this single scheduler.

These are some stats from a server we have:
~1600 RPM
~400 rooms (So we have 400 schedulers)
~1400 players

[ApolloMeijer]

I was reading my post again and noticed I said "So we have 400 schedulers" This is not true, we have 400 tasks scheduled (for every room one)

[Lapo]

You're running a heck of a lot of requests... Are two servers (SFS and the other HTTP server) in the same local network? If not this is likely to be a performance bottleneck.

In any case, as regards the scheduler you can reconfigure the system scheduler with a larger thread pool, via the AdminTool > Server Configurator.

Alternatively you can create your own scheduler in the Zone extension and share it with all Rooms, either case there's no difference in terms of performance.

Hope it helps

[ApolloMeijer]

Hey

The 2 servers do not connect through local networking, we found a few issues with the way we call the API so we are working on that.
Another thing that popped up during our investigating is that the outgoing messages queue is having huge spikes at any ccu, happens at 400 ccu and at 1600 ccu. outgoing message queue is always 0 or 1000+. We build the server on a larger amazon instance that suppose to give us more bandwidth but that didn't change anything. Can this be a problem?

We do not send any bulk messages to users.

[Lapo]

The 2 servers do not connect through local networking, we found a few issues with the way we call the API so we are working on that.

If you have any chances to put the two servers (sfs and http) in the same network, by all means, do it. It will save you a lot of headaches

Another thing that popped up during our investigating is that the outgoing messages queue is having huge spikes at any ccu, happens at 400 ccu and at 1600 ccu. outgoing message queue is always 0 or 1000+. We build the server on a larger amazon instance that suppose to give us more bandwidth but that didn't change anything. Can this be a problem?

Quick, temporary spikes are of no concern. If however these spikes take a long time to go away it sounds like you're hitting the clients with too much data. The server can only push as much data as the client can receive, so everything else is queued up.

One final reasons for spikes could be sending data in for loops. I'd recommend to avoid like the plague As it will cause performance issues. You can always aggregate data and send it at once.

Cheers