1 / 30

Evaluating Web Software Reliability

CSI518 – Group 1. Evaluating Web Software Reliability. By Zumrut Akcam, Kim Gero, Allen Chestoski, Javian Li & Rohan Warkad. Agile Development. How does Agile work? How did our class use Agile? 3 Sprints “Stand up” meetings at beginning of each class

chi
Download Presentation

Evaluating Web Software Reliability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSI518 – Group 1 Evaluating Web Software Reliability By Zumrut Akcam, Kim Gero, Allen Chestoski, Javian Li & Rohan Warkad

  2. Agile Development

  3. How does Agile work? • How did our class use Agile? • 3 Sprints • “Stand up” meetings at beginning of each class • Retrospective at the end of each sprint The Agile Development Process

  4. Overview

  5. What is reliability for Web applications? • The reliability for Web applications can be defined as the probability of failure-free Web operation completions.[1] • Failure is “the event of a system deviating from its specified behavior like obtaining or delivering information”.[2] Definition of Reliability

  6. Failures are caused from the following sources: • Host, network or browser failures: computer systems, network or software failures, etc. • Source content failures: missing, inaccessible files, JavaScript errors, etc. • User errors: improper usage, mistyped URLs.[1] Failure Sources

  7. To strengthen the reliability of Web applications by minimizing the number of source content failures. • Attempt to extend work on testing the reliability of websites. • Gain experience doing a research project Project Goal

  8. Sprint 1

  9. Read relevant research papers • Identify factors that may effect reliability analysis • Determine a system to analyze reliability on • Gather access and error logs Sprint 1 Goals

  10. Byte Count • User Count • Session Count • Error Count Factors That May EffectReliability Analysis

  11. Reliability analysis via error logs • Variety of reliability requirements • Commercial and non-commercial • We will try to record the technologies the websites employ (Apache, DNN, ISS, PHP, ColdFusion, etc..) System to Analyze Reliability On

  12. Sprint 2

  13. Collect log files for calculation • Automate processes to extra data (user, session, byte, and error counts) • Convert them into excel format • Log Parser Sprint 2 Goals

  14. DNN Logs (10 Websites) • PHP Logs Sprint 2 Progress

  15. .NET version of Drupal • An open source platform for building websites and web applications based on Microsoft .Net technology. • Leading open source ASP.NET web content management • Has been downloaded over 6 million times • ~100 employees • 5th Version • Founded 2006 What is DotNetNuke (DNN)

  16. Logs from 10 Websites • Window Server (Same Server) • SQL Server 2008 • ~1000 unique visitors per day • Logs contain • User count • Limited Error count Our DNN Logs

  17. Our DNN Logs does not contain • Session count • Byte count Major Problem

  18. Generate our own DNN logs Alternative

  19. Sprint 3

  20. Technologies Used • Windows XP Professional • Microsoft Internet Information Servers (ISS) • Microsoft SQL Server 2008 • DotNetNuke (DNN) • Logs Generated • Client IP’s • Byte Counts (Uploaded & Downloaded) • Time-Taken • Status Code Server Side

  21. Clients • Web-Crawlers • DotNetNuke Client API • Inducing Errors Generating Logs

  22. Results

  23. Server log data consisted of 23 consecutive days of data. • Page Not Found (Error 404) is the most common type of error in our logs, with 46% of total recorded errors. • Accessing forbidden data (Error 403) follows with 41%. • 72 unique IPs, 32970 hits total, and each hit associated with average 5020 bytes. Workload Measurement Facts

  24. Error/Success Ratios

  25. Status Code-Bytes Graphic

  26. 500-Internal Server Error Profile

  27. Number of errors

  28. Average Time Taken By Different Errors

  29. By Nelson Model, the site software reliability is R = 0.966, or that 96.6% of access to website is successful. • This model also shows that MTBF=29.6 hits or the site averages one error for every 29.6 hits. • From the number of errors chart, we can see that Server errors are very few among the other errors which shows what the reliability of the DNN server is. Conclusions

  30. [1] J.Tian, S.Rudraraju, Z.Li, “Evaluating Web Software Reliability Based on Workload and Failure Data Extracted from Server Logs”,2004. [2] T.Huynh, J.Miller, “Another viewpoint on 'Evaluating Web Software Reliability Based on Workload and Failure Data Extracted from Server Logs'”,2008. [3] G. Albeanu, A. Averian, I. Duda, “Web Software Reliability Engineering”,2009. Conclusions

More Related