Revised 2.7
This commit is contained in:
parent
c4a1af1dc1
commit
f69b8e6b3b
1 changed files with 23 additions and 9 deletions
30
report.lyx
30
report.lyx
|
@ -663,6 +663,13 @@ textbf{Software failiure}}{A failiure in software (the GGS, the operating
|
|||
|
||||
\begin_layout Section
|
||||
Background
|
||||
\begin_inset CommandInset label
|
||||
LatexCommand label
|
||||
name "sec:Background"
|
||||
|
||||
\end_inset
|
||||
|
||||
|
||||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
|
@ -2479,7 +2486,7 @@ name "sec:Scalability"
|
|||
|
||||
\begin_layout Standard
|
||||
Each instance of the GGS contains several tables.
|
||||
Each table is an isolated instance of a game, for example a chess game
|
||||
Each table is an isolated instance of a game, for instance a chess game
|
||||
or a poker game.
|
||||
The way that the GGS scales is to distribute these tables on different
|
||||
servers.
|
||||
|
@ -2490,11 +2497,11 @@ Each instance of the GGS contains several tables.
|
|||
down at a new table, all within the same game session.
|
||||
Therefore, the main focus of the GGS is not to move players among tables,
|
||||
but to keep a player in a table, and to start new tables instead.
|
||||
When a server has reached a certain number of players the performance will
|
||||
start to decrease.
|
||||
When a server reaches a certain number of players the performance will
|
||||
start to decrease, or worse, the server may even crash.
|
||||
To avoid this the GGS will start new tables on another server, using this
|
||||
technique the players will be close to evenly distributed among the servers.
|
||||
It is important to investigate and find out how many players that are optimal
|
||||
It is important to investigate and find out how many players are optimal
|
||||
for each server.
|
||||
This approach makes it possible to use all resources with moderate load,
|
||||
instead of having some resources with heavy load and some with almost no
|
||||
|
@ -2502,16 +2509,23 @@ Each instance of the GGS contains several tables.
|
|||
\end_layout
|
||||
|
||||
\begin_layout Standard
|
||||
As mentioned in the purpose section there are two different types of scalability
|
||||
, structural scalability and load scalability.
|
||||
As mentioned in section
|
||||
\begin_inset CommandInset ref
|
||||
LatexCommand ref
|
||||
reference "sec:Background"
|
||||
|
||||
\end_inset
|
||||
|
||||
there are two different types of scalability, structural scalability and
|
||||
load scalability.
|
||||
To make the GGS scalable both types of scalability are needed.
|
||||
Structural scalability means in our case that it should be possible to
|
||||
add more servers to an existing cluster of servers.
|
||||
By adding more servers the limits of how many users a system can have is
|
||||
increased.
|
||||
Load scalability in contrast to structural scalability is not about how
|
||||
to increase the actual limits of the system.
|
||||
Instead it means how good the system handles increased load.
|
||||
to increase the actual limits of the system, rather it means how good the
|
||||
system handles increased load.
|
||||
The GGS should be able to scale well in both categories.
|
||||
\end_layout
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue