(RADIATOR) correction to results: benchmarking and performance: multiple in stances

[Tariq Rashid]

A small correction to the previous post - ....

Is it possible that we are hitting a bottleneck in the imput queue
processing in radiator? These experiments, and previous ones, seem to point
to this fact in our configuration - the backend (ldap, sql) doesn't seem to
be too significant?

tariq

-----------------------

Here's a small correction to the previous results. The primary conclusions
are not affected.

See updated pdf graphs. 

	* The use of a proxy adds latency to the server. 
		Thus, the previous base response time of 0.075 seconds
		is now nearer 0.1 seconds. This obviously has an effect on
the
		maximum request rate ... which was calculated incorrectly
previously...

		This has been check over many experiments. See attached pdf.


	* The use of proxying (and the latency it adds) reduces the critical
		rate from the previous 17 per second ... down to about 13
per second.
		See attached graph to see the relative difference. 

		This too has been checked over many experiments. See other
attached pdf.

The following 2 conclusions can therefore be added to the previous ones:

	* the use of proxying introduced a constant latency to the radius
response,
		increasing the base "happy" time from about 0.075 s to
nearer 1.0 s.

	* the use of proxying is not recommended when the primary problem
being addressed
		is spiked in the request rate - proxying has a negative
affect on this.
		Proxying is used to solve the problem of heavy backend
computation, and
		does not help when the bottleneck appears to be input queue
related.

I'll mention this to the developers mailing list for their comments. 
Tariq

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.