From: Patricia Shanahan on
Barb Knox wrote:
> In article
> <ac070d06-00ef-4e21-b259-ea335b31ccd8(a)f20g2000prn.googlegroups.com>,
> Darren <anon5874(a)yahoo.com> wrote:
....
>> Also, I am still troubled by resource utilization. I have seen
>> implementations where the server busy loops waiting for messages to be
>> processed. It would seem that taking the resource utilization as
>> reported by the OS would be misleading in this scenario, since at the
>> point the message comes in (which could be random), the message might
>> be processed immediately.
>
> In the abstract world of queuing theory, utilisation is the fraction of
> the time that the server is busy actually servicing arrived requests.
> If it's not servicing a request then it's not considered busy
> (regardless of whatever else a real server computer might be doing then).

Also, if the server is dedicated to serving some request it is busy even
if it is waiting for a disk read, and not using CPU time.

Patricia
From: Patricia Shanahan on
Darren wrote:
> On Nov 30, 1:56 am, Tim Little <t...(a)little-possums.net> wrote:
>> On 2009-11-30, Darren <anon5...(a)yahoo.com> wrote:
>>
>>> One thing troubles me, and that is how resource utilization is
>>> defined?
>>> Let's say that I have a server request exactly every 1/10th of a
>>> second.
>> The formula above is typically based on conditions of a specific type
>> of *random* arrival distribution. If you violate the conditions, the
>> formula does not apply.
>>
>> - Tim
>
> Perhaps you can elaborate on the exact conditions when this formula
> applies? Does it need to be a Markov process?

I have seen it proved for Poisson process requests. I don't know whether
it is correct for any other cases. For practical queuing analysis, it
works well at low to moderate utilizations.

At high utilizations, in the real world, there are other effects that
become dominant. For example, at some service time the clients will
decide the server is unresponsive. Their possible reactions include
ignoring that server, or even causing it to be rebooted.

There may be a finite number of clients each of which has a finite upper
bound on the number of outstanding requests. That caps the queue size,
and will cause reductions in the request rate long before the maximum is
reached.

End users will decide not to use that web site. Would-be coffee drinkers
will go elsewhere or do without if the line extends out of the
Starbuck's door.

I have not found a satisfactory substitute for simulation when it comes
to understanding how a system behaves at high utilization.

Patricia
From: Reinier Post on
Patricia Shanahan wrote:

>Darren wrote:
>> On Nov 30, 1:56 am, Tim Little <t...(a)little-possums.net> wrote:
>>> On 2009-11-30, Darren <anon5...(a)yahoo.com> wrote:
>>>
>>>> One thing troubles me, and that is how resource utilization is
>>>> defined?
>>>> Let's say that I have a server request exactly every 1/10th of a
>>>> second.
>>> The formula above is typically based on conditions of a specific type
>>> of *random* arrival distribution. If you violate the conditions, the
>>> formula does not apply.
>>>
>>> - Tim
>>
>> Perhaps you can elaborate on the exact conditions when this formula
>> applies? Does it need to be a Markov process?
>
>I have seen it proved for Poisson process requests. I don't know whether
>it is correct for any other cases. For practical queuing analysis, it
>works well at low to moderate utilizations.

[...]

>I have not found a satisfactory substitute for simulation when it comes
>to understanding how a system behaves at high utilization.
>
>Patricia

Just to illustrate this further: it's easy to come up with simple
theoretical process models in which no closed formual exists
for predicting resource utilization, while simulation works pretty well.

For instance, Markov processes can be extended by allowing a process
to have multiple preconditions for starting, and multiple postconditions
resulting from completion. E.g. a supermarket may have a pool of customers
queueing uip in line to pay, and a pool of cashiers to serve the customers;
then payment will only proceed if both a customer and a cashier are available,
and will make both available after completion; but the cashier may double
as some sort of assistnt elsewhere in he supermarket.

The result is some sort of stochastic Petri net.
I used to be the maintenance programmer for an editor and simulator
for such Petri nets (http://www.yasper.org/) which offers randomized
simulation for estimating resource utilization. The behavior of such
nets is exactly defined, yet they must be seriously constrained before
closed formulas for expected resource utilization become available
(a buddy of mine was working on this).

--
Reinier Post
TU Eindhoven