search

GameAnalytics / GA-SDK-CPP

Repository for GameAnalytics C++ SDK.
MIT License
20 stars 16 forks source link

GameAnalytics::onQuit takes too long #120

Open jknotten opened 2 years ago

jknotten commented 2 years ago

When the user quits the game, there is a pause while the last few events are processed (including the close session event). This is taking around 2 seconds on average. It's long enough that the spinning beach ball in Mac OS X and the circular wait icon in Windows shows, which gives an impression of unresponsiveness.

It would be nicer if the exit from the application was more immediate. How about if the end session event is posted next time the game runs? The analytics backend could make an assumption that the session has ended if no events have been posted for a certain amount of time, and then make it more accurate when the actual event data is eventually sent.

jknotten commented 2 years ago

Further to this, the onQuit can take a very long time (in the order of minutes) if the network is particularly flaky.

I have put together some changes. If there is interest, I can try to make a pull request so that we can get some form of this integrated into the main line.

The changes that I made were:

  1. Build iwth CURL with c-ares support. This allows DNS requests to be properly asynchronous, otherwise a flaky network can delay DNS requests which hangs the whole game when looking up the game analytics servers.
  2. Change the thread::wait calls to use a conditional variable to signal exit. This reduces the wait time to exit even when the network is functioning correctly.
  3. Implement CURL request timeout using the progress reporting functions ( CURLOPT_PROGRESSFUNCTION). In normal operation there is no timeout, however, when shutdown has been requested, the HTTP requests timeout and fail within 1 second. (I believe that the events are in any case saved to the SQL database and will be communication will be retried next time the game is loaded).

Testing:

On Windows, a useful tool is clumsy . I have tested with a lay of 3 seconds using the preset "all receiving packets".

On Mac OS X, a useful tool is Network Link Conditioner (part of Additional Tools for Xcode, a separate download) with a custom network profile (DNS Delay of 10000ms, Bandwidth 1kbps, Packets Dropped 99.9% and Delay 5s).