PQ71675: V5 - PERFORMANCE PROBLEMS WITH APPLICATION FILTERING | |||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description This apar belongs to: WAS.webui.applicationmanagement In a test with 100 applications defined in a cell and with 7 app servers started, a status query used 38 CPU seconds of processing across the dmgr, node agent and app servers. The time used is proportional to both the number of defined applications and the number of started app servers. The production cell will reach 200 applications and 70 running app servers this year. The time for a status check in this case would be 20 times larger than this test (2 times the applications and 10 times the started app servers), or 760 CPU seconds. This is not going to happen, since it would impact the productive work on all production WebSphere servers while it occurred. A WebSphere display and deployment system has been developed for internal use. This system maintains a map of applications to app servers. It always queries the minimum number of servers to obtain application status, and has good scaling behavior. Problems with the application filtering process in the admin gui magnify this problem. In principle, one could filter to a single application and then operate only on that application, avoiding the complete status checks. However, filtering has design limits and bugs that prevent effective use. These are listed in the section Problems with Application Filtering Summarizing the impact: No functions under Enterprise Applications can be used on a large cell without impacting the applications in the cell. These funtions cover listing applications, updating applications, starting and stopping applications, and viewing and updating properties of applications. "Install new application" can be reached without first selecting "Enterprise Applications", so is still available. Our experience with our own display and deployment system demonstrates that these functions can be delivered in a scalable fashion, but requires use of an application map and stringent use of filtering. WebSphere gui is not using an application map, and the filtering function is nearly inoperable. Problems with Application Filtering First problem with Application Filtering - The bulk of the elapsed time and CPU processing used when stopping an application from the admin gui is due to processing to determine the status of each application listed. This delay becomes pronounced with large application counts in a cell. To attempt to reduce the processing needed to stop and start an application, I first set filtering to Name followed by the exact application name and clicked Go. This gave a display with just one application with a very fast response. However, when I then selected that app and hit the stop button or start, the return screen lost filtering, and again determined the status of all defined applications. Second problem with Application Filtering - When more than 20 applications are selected the admin determines the status of all selected applications, even though only the first 20 are displayed. This is proven by the long response time to return the first 20 items, and the immediate response time to return the succeeding panels of 20. For large cells, this long response makes the admin gui less useful. Third problem with Application Filtering - There is no way to select filtering before first calling a full display of applications. For large cells, one cannot select "Applications > Enterprise Applications" without impacting all production WebSphere applications in the cell. Fourth problem with Application filtering - The only supported selection fields are application name and application status. We have added an application developer field that restricts lists based on the identity of the person making the query. Other selection fields that could help are app server name and node name. Fifth problem with Application Filtering - There is no ability to list applications without also requesting status. Sixth problem with Application Filtering - The preferences button fails, giving null pointer exception. Thus preferences cannot be utilized. java.lang.NullPointerException at com.ibm.ws.webcontainer.webapp.WebApp.getRequestDispatcher(WebAp p.java(Compiled Code)) at com.ibm.ws.webcontainer.webapp.WebApp.getRequestDispatcher(WebAp p.java(Inlined Compiled Code)) at org.apache.struts.tiles.ActionComponentServlet.processForward(Ac tionComponentServlet.java(Compiled Code)) at org.apache.struts.tiles.ActionComponentServlet.processActionForwLocal fix Problem summary **************************************************************** * USERS AFFECTED: All WebSphere Application Server Users * **************************************************************** * PROBLEM DESCRIPTION: Performance Problems with * * Application Filtering * **************************************************************** * RECOMMENDATION: * **************************************************************** Diplaying the list of applications from the Admin Console takes a very long time.Problem conclusion Modified Application Management code to improve performance.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 00I
Software edition:
Reference #: PQ71675
IBM Group: Software Group
Modified date: Mar 19, 2003
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.