This is sub-layout for documentation pages
This page sums up benchmark tests that were executed upon the game.
It is very difficult (I would say impossible) to fully automatize the tests, as client must connect,
and perform some action, moreover, server shall be deployed on heroku.
Considering, that deploying on heroku server takes minutes (because of compilation),
and must be done for any code change, and moreover, it is production server,
measuring times is difficult, unless implemented as hidden / toggleable feature in the server
code (and you could toggle the time measurement, or test from client \(\leftrightarrow\) you are admin)
Given application / algorithm, benchmark is test, in which the time of execution for algorithm is measured.
After the time is measured, input data is altered and measured again.
Usually, the point is to discover, how the system will behave with more input data: how much slower will it be?
How much more memory will it consume?
This contains only loading times where browser cache is used
(for making textures load quicker), however, cache has no effect on loading items!
Moreover, one item is chosen to be copied. It depends on item stats, how much data is sent over network
(because of default value optimalization).
So this is really just to get an idea.
Tested data was measure on game of version dev - 1.2.1, on localhost (transfer between 2 PC over wifi)
Loading times also include loading network dictionary, textures, and client javascript startup
| Number of item prototypes sent | Loading time |
|---|---|
| 0 | 383ms |
| 1 000 | 341 ms |
| 3 000 | 455 ms |
| 4 000 | 422 ms |
| 5 000 | 357 ms |
| 6000 | 420 ms, but connection crashes and it needs to be refreshed |
| 6800 | 391 ms |
| 8000 | 427 ms |
| 50 000 | 963 ms (with printing) |
| 100 000 | 3s 292ms |
| 500 000 | 5s 79ms |
| 1 000 000 | 9s 747ms |
| 1 500 000 | 14s 955ms |
| 5 000 000 | Server takes forever to serialize the data |
With increasing amount of items being sent, times are longer, and system (socketio) even crashes / times out.
Considering that the test was performed only on localhost, on real deployment server, situation would be worser:
longer loading times, more crashes / timeouts.
Therefore, sending all items / monsters to all newly connected client is not feasible solution for lot of data
