Berin Loritsch wrote:
> The sizing algorithms I gave work well when trying to size
> hardware/JVM strategies for existing software. Now,
> considering the example above, where 8,727,272 requests
> are processed within an average time, we can have only
> 2,618 responses that exceed 1 second.
>
> While I agree that incremental processing works best when
> the primary concern is scalability, it does not necessarily
> work as well with absolute processing.
True, and it doesn't work here at all, at least not in the way I outlined
it. The problem is this - the thread is supposed to know when it is about
to run out of time. But it can only know that if it knows that a GC sweep
is supposed to happen in X msec, or that the OS will re-schedule it in such
a way as to give it control back in Y msec.
So, since Java does not support call with deadline like Concurrent C, that
is, the call is guaranteed to return within a given time, or
report failure, there isjust no way the thread can measure its own time
and bail out in time.
As far as average response times are concerned, they do matter, but only as
input into a probability calculation. Namely, given an average response
time, how many of the requests will straddle a minor GC sweep or a major GC
sweep? Suppose a minor sweep takes 100ms and that there are no major
sweeps. This means that if the average processing time is < 900ms, we're
done. Also assume that each request actually does take 900ms, period. We
can with 100% certainty say that every request will take 900ms + time spent
in GC, and nothing more.
Now assume a processing time of X ms. A minor gc sweep time of s(min) and a
major sweep time of s(maj). Assume minor sweeps happen every t(min) ms, and
major sweeps every t(maj) ms.
If a request straddles a minor sweep, it will take X + s(min) msec, and if
it straddles a major sweep it will take X + s(maj) ms. Major GC sweeps are
on the order of one second, so X + s(maj) > 1000 ms and result in a lost
request. Minor sweeps are on the order of, say, 10 ms, so they are
survivable. They are also frequent, with t(min) being about 100 ms. t(maj)
is in my experience about 60000 ms. That is, once every minute, the VM will
really clean out its house.
The delay from minor sweeps are thus
d(min) = ceil (X / t(min)) * s(min)
and are fairly constant. With the values above, the value of d(min) is
about 90 ms, with X being 900 ms, so you can, by setting the response time
to an arbitarily low value always compensate for these minor sweeps.
The problem is the big ones. What is the probability that a request will
touch a major gc sweep? Consider the time from the end of one gc sweep to
the end of the next, t(maj). Of that time, s(maj) ms is spent gc'ing,
leaving
t(maj) - s(maj)
ms to do requests. But each request takes X msec, so it must start at
least X msec before the onset of gc. So we have
t(maj) - s(maj) - X
msec during which a request can start and be sure to finish before the
onset of gc (and thus break the 1000 ms barrier). Now, given a uniform
distribution in time of requests, the probability of success for a request
is:
(t(maj) - s(maj) - X) / t(maj)
or, for the values above, 96.8%. You can improve this by decreasing X, but
since X can never be negative, the best you can ever hope to get is:
(t(maj) - s(maj)) / t(maj)
or:
1 - s(maj) / t(maj)
or 98.3%. For 99.97%, you'll need, for a sweep time of 1 second, that the
VM only gc once every hour. (Once every 3333 seconds.) And remember, this
assumes X == 0ms! If you can not make X smaller than, say, 200ms, the best
you can hope for is 98%.
So the solution is to make the VM gc *often* but *little* or, *turn off gc
completely* and switch
to another system, gc like crazy and switch back. But I do not know how
possible that is.
> So, before we can
> really delve into the specifics of this system, we need to know
> how long the average response time takes--then we need to
> understand exactly how many responses we are expected to
> process in any one time.
>
> It can be done, but it isn't easy.
Amen to that...
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
