A node-webkit benchmark for the comparison between HTTP and TCP PVP data transfers.
HTTP:
- load a JSON file with jQuery.get as text '{ "data" : 123 }'
- use JSON.parse to parse (management logic)
- push result into storage array (management logic)
- repeat all steps 1000x
-> Average process time 6250 ms (10835 with 10ms timer)
TCP:
- open connection to TCP server
- send a "request" command
- receive data content as text '{ "data" : 123 }'
- use JSON.parse to parse (management logic)
- push result into storage array (management logic)
- repeat from 2nd step on 1000x
- close connection to TCP server
-> Average process time 215 ms
The benchmark of jQuery ajax calls and node-webkit TCP client/server calls to transfer JSON data is located here.
Looks like TCP is 29x (or 50x) faster than HTTP here, but:
- one PVP connection only!
- the HTTP test does not contain any server logic!
- data transfer in one direction only!
That is not realistic enough, let's continue ...
Client/server processes:
- HTTP transfer 2x client + 2x server
- TCP transfer 2x client/server
- HTTP management 2x client
- TCP management 2x client
So the overall process time for data transfer / management:
- HTTP 2x 6250 ms = 12500 ms (does not include the server delay yet!)
- TCP 2x 215 ms = 430 ms
CPU capacity:
- HTTP 100%/2*(n*PVPC)
- TCP 200%/2*(1*PVPC)
PVPC = PVP connection
The HTTP solution and parallel PVP connections:
- 2 * 100 ms server transfer logic delay with 1 PVP connection
- with 1000 PVP connections: 100 * 2 * 1000 = 200000 ms
The 100ms delay rests on this benchmark with MySQLi and contains 0.1 ms delay for each data write or read process.
It looks like a HTTP client without a timer has to wait up to 212500 ms (~3,5 minutes) instead of 430 ( ~0.5 seconds) with TCP, that might be 494x faster.
That is not realistic enough again, let's continue ...
It is realistic to transfer 1000x1 data set instead of 1x1000 data sets, because game data can have many dependencies. But it is more realistic that the dependencies between data sets can cause higher delays of management logic to calculate dependent data, which will reduce the amount of parallel connections to a HTTP server.
In reality the transfer logic of TCP might be (28,535+ 0,465 * n) faster and "n" is the amount of parallel connections to one HTTP master server. And it is more realistic to use a timer with HTTP to check for new server data, which will add another delay to the HTTP transfer time.
E.g. a timer with 10 ms delay as mentioned before: TCP might be (49,534 + 0,466 * n) faster.
On 1000 parallel connections TCP might be 516x faster than a HTTP solution.
Further benchmark notes:
The timer delay for each HTTP data transfer might be higher, if the server delay increases, because an interval logic has to wait longer for the next result. Such a dependency check is not included in the benchmark and a realistic environment includes two clients which increase the transfer times by their timer delay. And TCP/HTTP benchmark results depend on local connections, external connections can increase the transfer times additionally.
