Are you guys running on fewer servers than you were 6 months ago?



  • 0_1517246014142_2b49db43-2566-4c69-8c7d-473f8b4fd3ab-image.png

    Tick times getting worse across the board, but active player count seems to be about the same. This is despite all the work that has been done on sharding and isolating the VMs.

    6s ticks are pretty tedious. Furthermore, there seems to be some connection between tick rate and browser pageload time to even view the world. I'm getting fairly long pageload times on shard0 and that is worse than the actual tick rate being slow.

    If you need more servers please just charge more.

    If it's due to idle players taking up CPU resources, create a game mechanic that incentivizes other players to wipe them out.



  • @shedletsky Even if the active player count remains similar they will have grown in GCL, owned rooms, and cpu.


  • Dev Team

    We have 20% more servers than it was 6 months ago. Idle players don't take CPU resources, and we deactivate 10 CPU players when they are not active for 30 days. Please note that isolated VMs are still in development and not launched yet.

    As for page load time, could you please test it on a different hardware? Is it consistently bad for you or hangs occasionally? According to our tests, most pages load in less than 500ms. If you mean rooms graphics, than it may depend on your GPU and renderer settings as well.



  • 0_1517419110953_2f0ca0db-db0f-43e6-a553-8daacc23a10b-image.png

    7s ticks on shard0 and shard1!

    @artch On shard2, if I click on a room on the world map, my "time to room render" is 6 seconds. On shard0 it is 9 seconds. My naive speculation would be that (shard0 - shard2 tick time) / 2 would be the average increase in render time for shard0 over shard2 if there were something in room render blocking on world state update.

    I've seen these on two different machines (PC and Mac) on two different networks. Possibly if you profile shard0 vs. shard2 time-to-interactive load times you will see this skew too.

    I've never seen 500ms, so maybe you are measuring time-to-first-byte?


  • Dev Team

    @shedletsky Render time has nothing to do with ticks. It will render even if ticks are stopped. API and WebSocket servers are same for all shards. Render time mostly depends on how complex this particular room graphics are, and ability of your GPU to render it. On my middle-range laptop time to room render is about 2s on every shard. You may want to try adjusting your renderer settings, 6-9s doesn't sound normal at all.

    shard0 and shard1 ticks are having bad times for the last 2 days, we're trying to figure what is happening there. You can see the graph at our Status Page.



  • @artch Is the time that it takes the client to download the data that needs to be rendered correlated with the server tick rate?

    I don't have any data to back this up but it's always felt like first render happens faster when the tick speed is faster. I've been assuming that if the database is the main bottleneck for tick processing then it will also be slow to respond to the client's request for room data to render.



  • Are you guys using the browser-version? If so: try Chrome. Works with far better performance compared to Firefox at my work laptop (and no, I never play screeps at work) 😉


  • Dev Team

    @hyramgraff

    @artch Is the time that it takes the client to download the data that needs to be rendered correlated with the server tick rate?

    No, due to this:

    It will render even if ticks are stopped. API and WebSocket servers are same for all shards.



  • @eiskalt good tip, but I already use Chrome

    👍