Fair share request class specifies the relative importance of the request compared to other requests that the system must process.
For example, assume that WebLogic Server is running two modules. The work manager for ModuleA specifies a fair share of 80 and the work manager for ModuleB specifies a fair share of 20. During a period of sufficient demand, with a steady stream of requests for each module such that the number requests exceed the number of threads, WebLogic Server will allocate 80% and 20% of the thread-usage time to ModuleA and ModuleB, respectively.
Note: The fair share value is specified as a relative value, not a percentage. Therefore, in the above example, if the request classes were defined as 400 and 100, they would still have the same relative values.
Response time request class specifies a response time goal in milliseconds. Response time goals are not applied to individual requests. Instead, WebLogic Server computes a tolerable waiting time for requests with that class by subtracting the observed average thread use time from the response time goal, and schedules requests so that the average wait for requests with the class is proportional to its tolerable waiting time.
For example, assume that WebLogic Server is running two modules with response time goals of 2000 ms and 5000 ms, respectively, and the actual thread use time for an individual request is less than its response time goal. During a period of sufficient demand, with a steady stream of requests for each module such that the number of requests exceed the number of threads, and no "think time" delays between response and request, WebLogic Server will schedule requests for ModuleA and ModuleB to keep the average response time in the ratio 2:5. The actual average response times for ModuleA and ModuleB might be higher or lower than the response time goals, but will be a common fraction or multiple of the stated goal. For example, if the average response time for ModuleA requests is 1,000 ms, the average response time for ModuleB requests would be 2,500 ms.
Context request class assigns request classes to requests based on the user that made the requests. You can make this association at the level of individual users or by using user groups.
Note: If a web application's work manager references a context request class, the first user call will go through the default request class; subsequent calls in same session will go through the user-defined request class.