1

WWW SERVER PERFORMANCE MONITORING Software Requirements Specication (SRS)

Demessie Atinkut Astatikie, Kassahun Solomon, Matiullah Khan
Dep. of Telecommunication Systems School of Computing Blekinge Institute of Technology 371 79 Karlskrona Sweden

I. I NTRODUCTION With the growth of the Internet the networks became complex and difcult to manage. In particular the World Wide Web application is becoming important and its usability depends upon the performance realized by the WWW servers. Many organization have the log les as their only mean of monitoring.But managing web servers with log les is not scalable and difcult to handle when there are many web servers hosted by an organization. So the need to develop a tool that implements management of WWW servers with simplicity and effectively has arisen. In this project, which is developing a tool the monitors performance of WWW servers, we are going to develop a this tool which uses Simple Network Management Protocol (SNMP) infrastructure for the management of WWW servers. SNMP is based upon open standards and has already a huge deployment over the Internet. This paper describes the software requirements specication (SRS) for the tool we are going to develop in our project. II. P URPOSE The purpose of this document is to point out the functional, non-functional and system requirements of the WWW SERVICES management tool that we are going to develop in this project. A WWW service is provided or used by a client, a server or a proxy. Clients send out requests for information to server. Servers receive, process and respond to requests received from clients. Servers usually have access to local documents, which can be transferred to clients. A proxy is a special server, which acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy is able to translate between the client and the origin server. Our software tool will be used to manage WWW services that are running on client, server or proxy server. We will make our software modular so that it will be very easy to upgrade and scale it up for monitoring WWW servers in big networks.

IV. F UNCTIONAL R EQUIREMENTS The functional requirements that our software tool will fulll are listed below: A. Common GUI Interface i User authentication - Users should provide their username and password to gain access to the software tool. ii Admin and user rights - In addition to authentication, users will be entitled to different privilege levels so that the authenticated user will only have access to those he/she is authorized for. iii Add, modify and delete users and hosts - Depending on their level of privilege, authenticated users will be able to add, modify or delete users and hosts. The user credentials, privilege level and accounting will be saved in database. So, what each authenticated user has done will be registered and accounted for. B. WWW Services i. Name (IP), Status - Our software tool will provide the user option to add hosts to be managed or to discover hosts in a given network segment. The operational status of WWW service will also be given by the software. ii. Type of service (Server, client, proxy) - Depending on the type of service, managed hosts will be categorized as server, client or proxy. iii. Primary protocol - An identication of the primary protocol in use by service will be given by our software. For Internet applications, the Internet Assigned Numbers Authority(IANA) maintains a registry of the object identiers(OIDs) which correspond to wellknown application protocols. iv. Last change (data and time) - The date and time when the WWW service entered its current operational status will be given. v. Requests - A request is a document transfer protocol (DTP) operation which is targeted to a document and invokes an action on the target document. The request type species the action that should be performed. A request can have a document associated with it. a. Received requests- The received requests can be categorized according to the type of request received and we will keep track of the number of instance of each type. (1). Number of specic requests received - Gives the count of request types.

Figure 1.

WWW Server Performance Monitoring

(2). Number of all bytes per request received - Gives the size of data in all request types received counted in bytes. b. Generated requests - The generated request will also be categorized according to the type of request made. (1). Number of specic requests generated - Gives the count of request types.

III. S COPE The scope of our project will be limited to providing common GUI interface and managing basic WWW Services. GUI interface will be used for the purpose of user authentication, controlling admin and user rights, and adding, modifying and deleting users. The basic WWW Services include name (IP), status, protocol, last change, requests and responses.

(2). Number of bytes per request generated - Gives the size of data in all request types generated counted in bytes. vi. Responses - A response is a DTP protocol operation which is returned as a result of a previous (and associated) request. The response status indicates if the requested action was successful or if errors occurred. A response can have a document associated with it. a. Received responses-The received responses can be categorized according to the type of response received and we will keep track of the number of instance of each type. (1). Number of specic response received - Gives the count of response types received. (2). Number of bytes per response - Gives the size of data in all response types received counted in bytes b. Generated responses - The generated responses will also be categorized according to the type of responses made. (1). Number of response type generated - Gives the count of the response types generated. (2). Number of bytes per response type generated - Gives the size of data in all responses types generated counted in bytes. vii. Total number of requests successfully received and generated- The summary of requests received and generated by the managed host without errors as referenced by the wwwSummaryInRequests and wwwSummaryOutRequests MIB object identiers viii. Total number of responses successfully received and generated- The summary of responses received and generated by the managed host without errors as referenced by the wwwSummaryInResponses and wwwSummaryOutResponses MIB object identiers ix. Total number of content byte received and generated (transmitted)- The number of bytes of document received and transmitted as referenced by the wwwSummaryInBytes and wwwSummaryOutBytes object identiers. x. Probe on every T time (1 - 300 sec) and store the information into the database- SNMP getrequest messages will be sent to managed host every T time and the response will be saved to database. xi. Graphs for daily, weekly, monthly- The managed host will be probed every T time and the responses will be kept in the database. Using saved data from the database, graphs will be drawn summarizing daily, weekly and monthly results. Separate graphs will be drawn for each of the following: a. Number of requests received and generated by specic service. b. Number of request size in bytes received and generated by specic service. c. Number of responses received and generated by specic service. d. Number of response size in bytes received and generated by

specic service.

V. N ON - FUNCTIONAL R EQUIREMENTS Our software tool will be developed carefully so that it serves its purpose at optimal central processing unit (CPU) and Memory overhead on hosts that are going to be managed. We will also make sure that amount of management trafc that will be generated by our management software tool will be kept at optimal level. The probing rate will be adjusted to suite the kind of environment the software tool will be deployed. For example in fairly uncongested and fast link with high performance hosts, the probing rate can be made smaller. In addition, we will make sure that we have set appropriate probing rate that would address the issues of counter wrapping and management information base(MIB) update problems. Moreover, we will design the graphical user interface(GUI) in such a manner that the software will be easy to use and has interesting display of graphs and other outputs. VI. S YSTEM R EQUIREMENTS Our software tool will have the following system requirements: A. HTML HyperText Markup Language (HTML) is the main markup language for web pages. HTML elements are the basic building-blocks of our webpages. B. CSS Cascading Style Sheets (CSS) is a style sheet language used for describing the presentation semantics (the look and formatting) of a document written in a markup language. We will use CSS to style our webpages written in HTML so that our graphs and other outputs will be diplayed nicely. C. MySQL For our database, we will use MySQL which is the most used relational database management system that runs as a server providing multi-user access to a number of databases. Our software will write into, read of modify databases that will be created on the database server. D. PHP Is open source general purpose server-side scripting language that will be embedded into HTML document. We will use PHP to make queries to fetch values from or modify the database and show result of the operation on GUI by integrating it with HTML. E. PERL is open source high-level, general purpose, interpreted programming language. We will use PERL to send SNMP probes to managed hosts and it will be interfaced with PHP and MySQL to integrate it with the GUI and database server. F. Apache is open source web server software. We will implement apache for providing GUI to help our user interact with our software tool.

Figure 2.

System Requirement