DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22314>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22314 Performance Enhancement Summary: Performance Enhancement Product: Struts Version: Unknown Platform: All OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The enhancement I present below in intended to address the problem of performance when it relates to a particular user (or group of users) or a particular request (or group of requests). There are a number of reasons why a particular user may require better performance than the overall user base. Examples include: a user demonstrating application functionality to a group of executives or a potential client, a user processing a high volume of transactions during the course of a day and a user that frequently complains about the application’s performance. In the last scenario, performance for the particular user could be improved immediately, while more generalized performance improvements could be accomplished during a number of weeks or months. There are also a number of reasons why a particular transaction may require better performance that others. If a user has to fill out ten screens to complete a logical business transaction, she is more likely to take her business elsewhere if the first screen performs poorly than if the last screen performs poorly. Once she has invested the time of entering in a number of screens, she will be more willing to wait for the application to respond. Some requests may require closer monitoring than others requests. If a query that is not part of a session performs poorly, it could be rerouted to an overflow server. If the application performs poorly in general, many non-session requests could be rerouted. My concept centers around a class I call RequestThrottle. RequestThrottle would be called from ActionServlet. Upon receiving a request, ActionServlet would pass the request as a method parameter to RequestThrottle. RequestThrottle would return a request. The request passed from ActionServlet and the request returned from RequestThrottle may or may not be the same, depending on a number of criteria. Immediately prior to sending a response, ActionServlet would pass the response as a method parameter to RequestThrottle. RequestThrottle would look at request/response pairs and analyze them based on configured parameters. Users and transactions could be put into a configuration file along with maximum response times and priorities. If actual response times approach the maximum, RequestThrottle would take action. RequestThrottle would begin queuing low-priority requests to free up application resources for high priority requests. It would begin sending some non-session requests to an overflow server. It may begin logging requests. It may send messages to certain users giving them an estimate of how long their transactions are expected to take. If actual response times are lower than the maximum, RequestThrottle would be begin releasing queued requests. RequestThrottle would continually monitor and adjust the number of requests that are queued and released. The core concept behind RequestThrottle is having a class that can analyze response times and queue some requests to enable others to process more quickly. Please let me know if you have any interest in this enhancement. Thank you, Robert W. Dahl [EMAIL PROTECTED] (847) 478-8455 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
