The TomcatoMips indicator was just something to tell that it's not the raw CPU power which is important, but the estimated LOAD capacity of an instance.
Accounting informations should included average time to execute a request, number of thread in use (AJP/HTTP), estimated free memory... Just to be sure that when a tomcat (for example), is near overload, the next requests will be routed to another less loaded tomcat. 2006/6/22, Darryl Miles <[EMAIL PROTECTED]>:
Henri Gomez wrote: > Well you we always indicate some sort of CPU power for a remote (a sort > of bogomips) and use this in computation. Why should the CPU power matter, what if the high power CPU is getting all the complex requests and the lower power CPU is ending up with simple request (static content). You are better implementing it in control packets over AJP that can advertise that hosts current willingness to take on new requests on a 32/64bit scale. Call this a "flow control back pressure packet", a stateless beacon of information which may or may not be used by the client AJP. Then have a pluggable implementation at the server end of calculating that value and frequency for advertising it. All the apache LB has to do is work from that load calculation. All existing AJPs have to do is just ignore the packet. In the case of different horse power CPUs that factor is better fed into the server AJP algorithm by biasing the advertised willingness to take on new requests after a certain low level is reached. Only the server end of the AJP know the true request rate and how near that system is to breaking point. This scheme also works where apache may not see all the work the backend is doing, like if you have a different apache front end clusters linked to the same single backend cluster. Darryl
