基于.net的教學(xué)系統(tǒng)外文翻譯(范文)

1、 外文文獻(xiàn)資料（performance modeling for web based j2ee and .net applications）abstractwhen architecting an application, key non-functional requirements such as performance, scalability, availability and security, which influence the architecture of the system, are some times not adequately addressed. perfor

2、mance of the application may not be looked at until there is a concern. there are several problems with this reactive approach. if the system does not meet its performance objectives, the application is unlikely to be accepted by the stakeholders. this paper suggests an approach for performance mode

3、ling for web based j2ee and .net applications to address performance issues early in the development life cycle. it also includes a performance modeling case study, with proof-of-concept (poc) and implementation details for .net and j2ee platforms. keywordsperformance measures, performance modeling,

4、 performance testing, resource utilization, response time, throughput.i. introduction performance modeling is a structured and repeatable approach to model the performance of a software application. it begins during the early phases of the application design and continues throughout the application

5、life cycle 1. performance modeling allows evaluation of architecture/design before investing time and resources in full application development. the application performance objectives are specified in terms of response time, throughput, cpu utilization, network i/o, disk i/o and memory utilization.

6、when performance models are created, application scenarios are identified with the required performance objectives for response time, throughput and resource utilization (cpu, memory, disk, and network). application scenarios can represent a business function such as registration, placing an order,

7、transaction processing and asynchronous messaging. performance modeling enables predicting performance measures early in the lifecycle of the project. the obtained performance measures could help in refactoring architecture/design of the application and/or dealing with external factors to meet the d

8、esired performance objectives. ii. background and motivationthis paper provides an approach to conduct performance modeling of an application much before it is fully built. shankar kambhampaty is a principal technical architect with satyam computer services, hyderabad, ap india 500082 (phone:91-40-5

9、5237853 fax: 91-40-23303071; e-mail: shankar_kambhampaty s). venkata srinivas modali is a technical architect with satyam computer services, hyderabad, ap india 500082 (phone: 91-40-55237200 fax: 91-40-23303071; e-mail: srinivas_mv s).there are few research studies that have evaluated performance of

10、 applications and also best practices to achieve performance 1, 5, 9.these studies are complementary to this approach.performance model provides a mechanism to uncover the performance related facts about an application. the benefits of performance modeling include the following 1: evaluation of arch

11、itecture/design tradeoffs early in the life cycle based on measurements performance becomes a feature of development process and not an afterthought a proof-ofconcept (poc) was developed to address the requirements of an application in the financial domain. the poc was developed for both j2ee and .n

12、et platforms. performance modeling was done for pocs developed on these platforms. the approach for performance modeling, the results obtained and the conclusions are being shared in this paper.iii. performance modelsperformance models can be grouped into two common categories: empirical models and

13、analytical models. empirical models simulate the behaviour of the application. they measure the performance of the application by simulating virtual users. the main advantage of empirical models is they provide accurate results. this approach, however, requires significant effort with testing and da

14、ta capture being done on several runs of the application 2. this paper shares the results obtained using this approach. analytical models capture key aspects of a computer system and relate them to each other by mathematical formulas and/or computational algorithms. analytical models require input i

15、nformation such as workload intensity (e.g., arrival rate, number of clients and think time). several queuing network based algorithms are used to arrive at approximate performance estimates in analytical models 2, 3.a. performance testing performance testing is the process of capturing performance

16、measures by subjecting the application to specified set of conditions and input. for performance testing purposes, the application should be hosted on a hardware infrastructure that is representative of production environment. by observing the behavior of the application under simulated load conditi

17、ons, it is necessary to determine whether the performance measures tend towards or away from the defined performance objectives 1.the following are some of the performance measures that can be identified through performance testing: 1) response time 2) throughput 3) resource utilization (cpu, memory

18、, network i/o, disk i/o) performance testing is usually carried out with controlled and parameterized workloads. a key concept in load testing is the notion of a virtual user 6. there are many tools that help simulate the load. these include mercury loadrunner, compuwares qa load, rational performan

19、ce tester, microsoft application center test (act) and microsoft web application stress tool. performance testing with a tool can generate a system activity that mimics the behaviour of real users and reveals the problems they will encounter before the applications are released into production 8.the

20、 performance testing tools can simulate load in terms of users, connections and capture data related to response time, throughput and resource utilization. there are organizations such as the system performance evaluation corporation (sepc) that offers benchmarks and develops standardized performanc

21、e tests and publishes reviewed results 7.iv. approach for performance modeling the approach for performance modeling follows a nine step process as given below: 1) evaluate performance risk 2) identify and prioritize critical use cases 3) identify key performance scenarios for the use cases 4) defin

22、e performance objectives 5) construct proof-of-concepts (pocs) 6) conduct performance testing 7) determine and evaluate performance model 8) refactor poc 9) validate performance model1) evaluate performance risk: the time and effort invested up front in performance modeling should be proportional to

23、 project risk. 2) identify and prioritize critical use cases: application use cases for which performance is critical need to be identified. 3) identify key performance scenarios for the use cases: for the identified use cases, those scenarios that pose the most risk to performance objectives need t

24、o be identified. 4) define performance objectives: define performance objectives for each of the key scenarios. performance goals are stated in a simple and precise manner 3, such as: the application throughput should be greater than 500 query transactions per second with at least 95% transactions r

25、esponding in less then a 2 sec the server should be available 99.9% of the time during working hours the response time of a medical information system should be less than 1sec the server should provide an average response time of two seconds or less with 1000 concurrent users5) construct proofofconc

26、ept (poc): construct proof-of-concept that implements the architecture and design decisions meant to achieve the desired performance objectives. 6) conduct performance testing: the main goal of performance testing should be to identify how well the application performs against the performance object

27、ives specified in step 4. 7) determine and evaluate performance model: evaluate the feasibility and effectiveness of the model. review the performance objectives and consider the following questions 1: does the model identify a resource hotspot? are there more efficient alternatives? can the archite

28、cture/design be altered to meet the performance objectives?8) refactor poc: to refactor the poc, consider the following actions: modification of the code of poc modification of the architecture/design 9) validate performance model: the validation of model confirms that the architecture/design of poc

29、 can be used for the full application development to achieve the performance objectives. validate the model by measuring the performance of the use cases (actual results obtained by conducting the performance tests) and modifying the application until the performance objectives are met. v. case stud

30、yperformance modeling was performed for a proof of-concept (poc) that was developed for a loan management application in financial services domain for both j2ee and .net platforms. the major features of the poc, loan management system (lms) consists of a customer application and an officer applicati

31、on. the customer application enables the customer to register with the system, apply loans and view status of the loans. the officer application enables the loan officer to approve or reject a loan and view status of loans. the major use cases are given below in fig. 1. a. .net version of the poc th

32、e .net version of the poc is discussed in this section. the architecture for the .net version of the poc is shown infig. 2. the user of the application uses the browser to access the presentation layer of application which implements the mvc design pattern with uip block from microsoft 4. the reques

33、t for business functionality is passed to the service interface of the business layer. the business layer implements business processes for different modules. the data layer implements the daab block from microsoft. the data access components in the data layer encapsulate the data sources from the b

34、usiness layer. components and frameworks selected for .net version of poc are provided in table i. uip, edra and daab are three reusable frameworks for implementing functionality of presentation, business and data layers developed by microsofts patterns and practices group 4. the application was dev

35、eloped in c#.net running on windows xpserver and database is sql server 2005. the iis web server, the c# business components and the database server were running on separate servers. these are represented as app1, app2 and db table iii and table iv respectively. b. j2ee version of the poc the j2ee v

36、ersion of the poc is discussed in this section. the architecture for the j2ee version of the poc is shown in fig. 3.the user of the application uses the browser to access the application. the request from the browser passes, on (over http) to the presentation layer which implements the mvc design pa

37、ttern. the presentation layer is implemented with the struts framework. the request for business functionality is passed to the business layer. the business layer implements business processes for different modules as java objects andenterprise java beans (ejb). the data layer implements the data ac

38、cess object (dao) pattern. the data access components encapsulate the data sources from the business layer. components and frameworks selected for j2ee version of poc are provided in table ii. the application is developed in java running on windows 2000 server and database is oracle 10g. the web ser

39、ver, application server and the database were running on the same system.c. performance modeling of pocs for .net and j2ee platforms performance modeling based on the nine step approach was conducted for the pocs developed for .net and j2ee platforms. it must be mentioned that the purpose of the exe

40、rcise was to determine the performance models of the pocs that were developed based on identified frameworks for the respective platforms. benchmarking .net and j2ee was not the objective of this exercise and hence the performance tests were not run on machines with exactly similar configuration and

41、 with same testing tools. the performance testing for .net poc was conducted using loadrunner where as the performance testing for j2ee poc was done using act. step 1: evaluate performance risk: performance modeling is critical for this financial application as it a web based and distributed applica

42、tion. step 2: identify and prioritize critical use cases: the critical use cases considered were “l(fā)ogin” and “registration”. step 3: identify key performance scenarios for the use cases: the key scenarios are those involving execution of the use cases by 300 concurrent users. step 4: define performa

43、nce objectives: the performance objective is to meet 2 second response time with 300 concurrent users. step 5: construct pocs: the pocs were constructed the architecture diagrams of which have been given in fig. 2 and fig. 3.step 6: conduct performance testing: performance tests were conducted, resu

44、lts were measured and the bottlenecks were identified. the performance objectives considered were 1) response time 2) throughput 3) cpu utilization 4) disk idle time for .net version of the poc the performance testing was conducted using loadrunner tool and the test results for login and registratio

45、n use cases are provided in table iii and table iv respectively. note: app1 = web server deployed on intel machine, 1 gb ram, dual processor 2.7 ghz app2 = app server deployed on intel machine, 1 gb ram, dual processor 2.7 ghz db=db server deployed on intel machine, 1 gb ram, dual processor 2.7 ghzt

46、he following are the observed performance results: 1. for read-intensive operations, web server cpu utilization peaked at 94% and app server cpu utilization peaked at 88%. 2. for write-intensive operations, web server cpu utilization peaked at 74% and app server cpu utilization peaked at 48%. 3. non

47、e of the resources were 100% utilized indicating a possible network bandwidth, thread pool or locking issues.for j2ee version of the poc the performance testing was conducted using microsoft application center test (act) and the test results for login and registration use cases are provided in table

48、 v and table vi respectively. the following are the observed performance results: 1. for read-intensive operations, cpu utilization peaked at 92%. 2. for write-intensive operations, web server cpu utilization peaked at 97%. 3. the results obtained indicated that the limitations were network bandwidt

49、h and queue length issues.step 7: determine and evaluate performance model: the performance models were evaluated for pocs on .net and j2ee platforms and found to satisfy the given performance objectives. the results indicated that the limitations were network bandwidth and queue length issues, whic

50、h are external to the application. as there was no problem with the application, the refactoring of the application was not necessary.vi. realized benefitsthe performance modeling has provided insights into the suitability of the architecture/design and implementation frameworks in achieving the per

51、formance objectives of the application. this performance modeling approach has also helped in identification of bottlenecks. it is possible to come up with strategies to overcome the bottlenecks and also predict the performance for the fully built application. any rework due to architecture/design a

52、nd implementation defects on account of shortcomings in addressing performance requirements is eliminated on account of this approach. vii. conclusionperformance modeling in the early stages of application development helps to expose key issues in architecture, design and implementation and provides

53、 pointers to trade-offs that may need to be made to achieve the performance objectives. an approach involving identification of key use cases, key scenarios and capture of performance measures such as response time, throughput and resource utilization has been discussed in this paper.references 1 mi

54、crosoft, improving .net application performance and scalability. patterns and practices, microsoft corporation isbn 0-7356-1851-8. 2 s. kounev and a. buchmann, “performance modeling and evaluation of large-scale j2ee applications”, in proc. 2003 computer measurement group conference (cmg-2003), dall

55、as, texas, december 7-12, 2003. 3 d. a. menasc, v. a. f. almeida, l. w. dowdy, performance by design: computer capacity planning by example. prentice hall, 2004, isbn 0-13-090673-5. 4 microsofts patterns and practices group, available : 5 c. u. smith and l. g. williams, performance solutions: a prac

56、tical guide to creating responsive, scalable software, addision-wesley. 6 d. a. menasc, “l(fā)oad testing, benchmarking, and application performance management for the web,” in proc. 2002 computer management group conference, pp., 271-281, reno, nevada, december 2002. 7 system performance evaluation cor

57、poration, available: / 8 j. shaw “web application performance testing a case study of an on-line learning application,” bt technology journal, vol.18, no 2, april 2000. 9 c. u. smith, l. g. williams, “best practices for software performance engineering”, in proc. cmg, dallas, dec. 2003.中文翻譯稿翻譯： 應(yīng)用技術(shù)學(xué)院 06計(jì)算機(jī)1班（0616403009）景晶2010年2月（網(wǎng)絡(luò)性能建模的j2ee和.net應(yīng)用）摘要，當(dāng)設(shè)計(jì)應(yīng)用程序時(shí)，重要的非功能需求，像性能，可擴(kuò)展性，可用性和安全性，有些時(shí)候沒有充分解決，這影響了系統(tǒng)的體系結(jié)構(gòu)。直到遇到一個(gè)問題時(shí)，應(yīng)用程序的性能才會(huì)被看到。有些問題是被動(dòng)方式的。如果系統(tǒng)不能滿足其性能目標(biāo)，應(yīng)用程序不可被利益相關(guān)方接受。本文提出了以網(wǎng)絡(luò)的性能建模方法為基礎(chǔ)的j2ee和.net應(yīng)用程序的性能問題，以早日解決在開發(fā)生命周期的性能問題。對(duì)于.net和j2ee平臺(tái)的概念驗(yàn)證（poc