At present, IT technology is supporting key business applications, such as manufacturing ERP systems, telecom BOSS systems, banking core business systems, card business systems, and e-commerce-based business. Key business applications have high performance, performance declines often cause huge losses to the business. In the face of these problems, there is a need to have a series of tools and methods to monitor and manage the performance of the IT system, and timely, accurately analyze and process possible performance issues. Thereby improving service quality, reducing operation failure and risk of disaster, reducing the overall cost of maintenance operations, improving system availability, shortening response time, and improving the final customer satisfaction. Application System Performance Management The scope involves all aspects of enterprise applications and terminal applications, such as print devices, storage devices, databases, application servers, networks, web servers, operating systems, user application software, and more. The scale of application system performance management can summarize whether the user's request is quickly processed, whether the resource of the system is reasonably utilized, and whether the system can continue to run continuously and other three aspects. DETAILED DESCRIPTION Minutes can be divided into five steps: 1. "See Know", take the initiative to discover problems to establish a problem alarm mechanism. In system operation, a large amount of information will occur from the network, operating system, database, application server, web server, etc., which may indicate a potential performance problem, which requires flexible customization of alarm mechanism, and The administrator can be notified by a variety of alarm mode (email, mobile phone text messages, etc.). The potential performance issues of the application system should be discovered as much as possible in the early stage of the application system. Although the system is not large in early general load, the microscopic changes in system resources can be obvious by using monitoring tools. Most of the problems are the early discovery of the system operation. Most problems are to reflect from the basic operating system, the network's level, such as memory excessive consumption, high usage rate of the CPU, frequent starting or quantity of the process, etc. So common monitoring objects are usually: CPU, Disk I / O, Network, File System, Process, User, MIBII, System Log, Web Server, etc. In order to find problems related to a particular application system, it is necessary to establish a rule, for SAP, PeopleSoft, Oralce, WebLogic, and other software systems, specific alarm rules should be established. 2. "According to Tuo" diagnostic problem, quickly identify performance bottlenecks, depend on more accurate monitoring information. Regardless of the problem occurs in operating system, storage, database, application, application server or webserver, etc .; we need to collect useful system information with software tools, provide rich real-time views and reports, directly in each monitored system Collect the end-to-end accurate information. On the basis of this information, real-time and historical analysis are performed. Quick and clear supplier responsibilities are conducive to rapid solving problems. The current application system is increasing, involving providers providing hosts, storage devices, operating systems, databases, application servers, application software, and large number of interfaces between them. After the problem, it is difficult to quickly find problems. The root of the roots, and for some problems, it is difficult to find enough data to clarify the supplier's responsibilities. 3. Expertive recommendations provide systematic expertise, providing basis and possible programs for rapid solving problems; in-depth analysis of issues: excavation, consult experts, find suggestions from performance management tools, or access internal knowledge base Get the recommendations and means of problem solving.
A good knowledge base, not only recording the technical information of the relevant issues, and also records who should find, where can I get help. Knowledge Base is an increasingly accumulated process, and some manufacturers have also begun to provide continuously updated diagnostic knowledge bases. 4. Solving the problem According to expert advice and programs, optimized test, test, verification, and evaluation, etc., the optimal solution is determined in existing solutions and implemented. 5. Daily maintenance guarantee the normal operation of the system, pay attention to system operation status, adjust the alarm rules, pay attention to the occurrence of new problems, and constantly improve service management level. By performance management, you can quickly understand the resource allocation and running mechanisms of the entire application system. Service Level Management (SLA) should be employed to establish an IT technology to implement the bridge of IT technology services, enabling the application of application system maintenance from management. Managing and reporting prioritizes on the SLA. By initializing the SLA definition, real-time and historical data can be provided, and the future of the future to SLA can be foreseen, and the SLA is adjusted based on this data. "Application performance problem is in a dark room, you know some problems in this black house, but you don't know what is in the house, and I don't know where it is. At this time, the application performance management software is a good ratio. Bright lights, after these software tools, the entire black house is bright, you can very accurately, easy to identify the problem, find out the cause of the problem, and fix it immediately. "Here is an excellent performance Managing Tools US Quest's FOGLIGHT will help manage J2EE applications. As J2EE's enterprise applications are increasing, in practice, it is facing a lot of risks, and many of the performance issues in the system come here. This is because J2EE application servement reflects the "black box" idea, user or developer's details are unclear; developers only develop business logic code, and the database connection, message, etc., which have been standardized, is not familiar with it. The implementation of these standardized resources; current J2EE has developed very quickly, in many project construction, technicians generally lack experience in J2EE, experts are very lacking; Java itself is difficult to debug, especially those in operation, more difficult. J2EE contains many components, including client software, web servers, application servers, database servers, and so on, and troubleshooting is particularly difficult. In Foglight, the source of monitoring management information is primarily: resource usage, including various application pools and caches; J2EE application servers via JMX information; application server / operating system, etc. Error logs. 1. Discovery Problem The appropriate rules of the Foglight definition discovery problem are key steps for application performance management. In practice, it can be considered from three aspects: a) In terms of availability: When there are 20% of the server in the cluster, issue a warning When there is an 80% server downtime in the cluster, a critical alert is issued; when there is a 100% server downtime, or a non-set server downtime, a fatal error is issued; b) In terms of service performance, it needs to be applied Design and load definition rules: JDBC Pools, most applications have a database-centric, adjusting the number of JDBC Pools has a significant impact on the performance of the application. Determine the JDBC Pools threshold based on the application's design and load, the system will alarm when the threshold is reached. EXECUTION QUEUES determines the threshold of the thread based on the actual situation of the application.
JMS Servers, based on the design and load of the application, determine the threshold of bytes / messages, and the system will alarm when the threshold is reached. Message Driven Bean and Stateless Session Bean Pools, if Beans is not available, the request must wait until it is obtained. Determine the Message Driven Bean and Stateless Session Bean Pools threshold according to the application design and load, the system will alarm when the threshold is reached. Entity Bean and Stateful Session Bean Caches, when Beans transitions passivated or activated (passidated, actid), a large number of disk I / O will significantly reduce performance, and the system can generate alarm. Rollbacks, system errors, insufficient resources, timeout abnormalities, etc. generated by transaction rollback can seriously affect the successful completion of business processing. Log files, determine different alarm mode (Warning, critical, Fatal) based on the severity of the message of the WebLogic log. c) In terms of application performance: response time, reaction time: alarm threshold for the response time of the related class or method, which can be determined by the history record of these classes or methods. The alarm level can be determined according to the gap between the history record. Rollbacks, the severity of the alarm is related to the proportion of the number of returns to all transactions. The rollback of the application transaction may be normal (for example, check data), but when the proportion of the application rollback will mean the error. 2. Diagnostics: Foglight monitors and issues an alert based on pre-defined rules. Foglight provides a wealth of associated charts for monitoring object types to display the response time of classes or methods, JDBC Pool, JMS, Entity Beans, Stateful Session Bean, Execution Queues, and so on. Where garbage collection and HTTP session is a symptom symptoms common to write Java application code. a) Garbage Collection: FOGLIGHT provides charts to display the number of garbage recycling and the number of memory each recycled, can determine the efficiency of the application uses memory. If there is a lot of more memory every time, it means that the application does not use memory resources correctly; if there are fewer memory per reclaim, it means that the application is healthy in use. b) HTTP session: Foglight can display the number of HTTP sessions per app on the application server. It is possible to analyze if the timeout configuration of the HTTP session is appropriate, and the session can calculate the consumption of memory. If there is a lot of sessions, you need to pay attention to the amount of memory used for each session. 3. Expertry recommendations According to experience, experts from three aspects: Foglight and Spotlight (Quest's diagnostic products) online help provide a lot of practical recommendations. System maintenance team's work log or knowledge base system. J2EE Application Server Suppliers and Application System Developers' Technical Consulting Team. 4. Solving the problem On the basis of expertnicity, a technically experienced technical team is needed. The technical team not only requires rich experience in the system and the development of Java, but also has the correct solution and method of solving problems.
