On Saturday, 8 February 2014 at 16:41:42 UTC, Paulo Pinto wrote:
In the stock exchange there are Java and .NET systems doing
transactions at faster speed than that.
100ms is too much money to be lost if the transaction course
changes.
It might be worth referring back to Don's talk at least year's D
conference. His company does targeted advertising, and if I
remember correctly, their entire transaction response time limit
including time on the wire is around 40ms. It's small amounts
rather than potentially millions per transaction, but either way,
for many network services these days, profit is directly tied to
exceedingly rapid response time.
Even for cloud services, let's say a user is willing to accept a
500ms transaction time, including transport. Now let's say the
could service has to talk to 5 other services to process the
request, each which has a normal transaction time of 50ms. If
one occasionally spikes to 250ms, that's a problem for that one
request, but it's an even bigger problem for all the requests
piling up behind it, since in this case the entire process is
blocking on a garbage collection. Under very heavy load, the
process may not even be able to recover. You can see this in
Netty for Java, as it has a fixed request queue size (defaults to
like 5) and once this limit is reached it just starts rejecting
requests. A long collection means request failures.
