Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce lag by reducing status block #430

Open
icydee opened this issue Feb 27, 2016 · 1 comment
Open

Reduce lag by reducing status block #430

icydee opened this issue Feb 27, 2016 · 1 comment
Labels

Comments

@icydee
Copy link
Member

icydee commented Feb 27, 2016

Status is returned for pretty much every API call. Fixes to reduce the overhead.

  1. Make the return of status optional, have an api argument no_status which over-rides the return of the status block. Client can (for example) then only request it if more than (say) 60 seconds have elapsed.
  2. Server can choose to send status anyway if something has changed (e.g. mail has arrived).
  3. For baby empires make the request for baby empires/planets a separate API call. We only need to get the planets for a baby empire when we open the empire in the Right Hand Menu.
@icydee icydee added the Reboot label Feb 27, 2016
@icydee
Copy link
Member Author

icydee commented Feb 28, 2016

We could turn this around, only send the status block on request. The server could have a cache value for 'significant events' for each empire. A significant event being anything that would change the empire, e.g. an email being read/received, a new colony being created/destroyed, essentia being spend/purchased.

A similar cache value for each body could be created to catch significant events (not, for example normal increase in resources, which can be calculated) but things like more incoming ships, a 'needs_surface_refresh' etc. This cache value would have a modest timeout, say 2 minutes to ensure that it is sent fairly frequently (but not always)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant