empirical study of performance of data binding in asp.net web applications

1、 Empirical study of performance of data binding in ASP.NET web applications Toni Stojanovski1, Marko Vu?kovi?1, and Ivan Velinov1 1Faculty of Informatics, European University, Skopje, Republic of Macedonia, toni.stojanov

2、ski@eurm.edu.mk, {vuckovic.marko, velinov.ivan}@live.eurm.edu.mk; Abstract—Most developers use default properties of ASP.NET server controls when developing web applications. ASP.NET web applications typically employ

3、server controls to provide dynamic web pages, and data-bound server controls to display and maintain database data. Though the default properties allow for fast creation of workable applications, creating a high-perf

4、ormance, multi- user, and scalable web application requires careful configuring of server controls and their enhancement using custom-made code. In providing commonly required functionality in data-driven ASP.NET

5、web applications such as paging, sorting and filtering, our empirical study evaluated the impact of various technical approaches: automatic data binding in web server controls; data paging and sorting on web server

6、; paging and sorting on database server; indexed and non-indexed database columns; clustered vs. non-clustered indices. The study observed significant performance differences between various technical approaches. Ind

7、ex terms — web applications, scalability, database access 1. INTRODUCTION In the last few years we are observing increased use of web applications. This is a consequence of many factors: zero-client installation, server

8、-only deployment, powerful development tools, growing user base etc. Furthermore, competition and the quickly changing and growing user requirements create a demand for rapid development of web applications. Microso

9、ft Visual Studio (MVS) is the dominant web applications development environment of today. MVS provides numerous mechanisms to support rapid development of ASP.NET applications. Most developers tend to use the defau

10、lt ASP.NET mechanisms: page caching; introduction of state in HTTP (session, cookies, hidden HTML controls etc.), data management, and the ASP.NET server controls which are arguably the most significant enabler of th

11、e rapid development. Though these mechanisms and ASP.NET server controls can significantly decrease the application’s “time to market”, at the same time they can reduce performance and scalability of the web applicat

12、ion. Analysis of factors which influence the response time of web applications is an active area of research [1]. In this paper, we demonstrate the importance of adding custom program logics to ASP.NET server contro

13、ls in order to improve performance and scalability of web applications. Here we put emphasis on the data binding mechanism, that is, the mechanisms used to maintain and display data. The other mechanism, such as data

14、 updating, page caching, data caching, state management etc. are left for future work. Here we address the following research questions: ? What is the impact of the paging mechanism on the response time? ? What is

15、the impact of indices on response time when sorting and paging the results? ? What is the dependence of the response time on the number of database records? ? What are the scenarios when it is better to use ASP.NET s

16、erver controls? When is it better to use custom stored procedures for fetching, sorting and paging the results? The outline of our paper is as follows. In Section 2 we are explaining the basics of data binding in ASP.

17、NET applications, how paging is used to cut the expenses for fetching and displaying data, and sorting the data by some field. In Section 3 we are explaining our test environment and the testing approach. Test enviro

18、nment is sued to measure the response time of various ASP.NET pages which implement various methods for data IF @pageNumber > 1 BEGIN SET @Ignore = @PageSize * @pageNumber SET ROWCOUNT @Ignore SELECT @LastID = ID

19、from testTable ORDER BY ID ASC END ELSE BEGIN SET ROWCOUNT @PageSize SET @LastID = 0 END SET ROWCOUNT @PageSize SELECT * FROM testTable WHERE ID > @LastID ORDER BY ID ASC Code 2. SQL Stored procedure which suppo

20、rts custom data sorting and paging. This stored procedure logically divides the records from table testTable into pages of size @pageSize records, and returns the records from page @pageNumber. Records are ordered by f

21、ield ID. Performance of this stored procedure greatly depends on the use of index on field ID and the type of index: clustered or non-clustered [4]. By using indexed data structure we can significantly improve the ti

22、me required for getting information out of the database. We expect major differences in response time depending on the following parameters: ? Number of records in database ? When paging and sorting is done by ASP.NE

23、T, or in SQL stored procedures ? Database indices ? Different deployment scenarios. These scenarios based on the previous parameters will be tested in our test environment. 3. TESTING APPROACH For our test envir

24、onment we used HP 550 Notebook with following characteristics: ? Processor: Intel(R) Core (TM)2 Duo CPU T5470 @1.60 GHz ? RAM: 2.00 GB ? OS: Windows 7 Professional 32 – bit ? Internet Information Services (IIS) Ve

25、rsion 7.5.7600.16385 ? Visual Studio 2010 Ultimate ? SQL Server 2008 Express (use only 1GB RAM) For the test environment we created a web application with three web pages – one for each of the data binding, paging a

26、nd sorting approaches as explained in Section 2. Test database, named testdatabase, has one table named testTable. The database has five fields. Records in the table are populated with random values. Name Type ID i

27、nt, autoincrement TextField varchar(50) IntField int BoolField bit DateField datetime Web pages use a GridView control to display the data returned from the database. Each web page uses a different mechanism to bind

28、 the GridView control with the data, and to sort and page the data. Sorting field and page number are passed to the web page in the query string for the HTTP request. We also created a windows application that sends

29、HTTP request to the IIS web server. Query string for the HTTP request contains a randomly chosen page number, and the sorting field. Figure 2. HTTP requests in the test environment We are interested in the time requir

30、ed to process a HTTP request on the web server. Requested page queries data from a SQL Server table. We used the ASP.NET tracing to determine when certain events in the page lifecycle occur, that is, the start and en

31、d point in the page processing. We start the timer at Page_Init event and end the timer at Page_SaveStateComplete event, which is after the Page_PreRender event. As the requests are sent to ASP.NET, the page gets the

32、 variables from the query string and therefore chooses which stored procedure to use. Web pages are responsible to record the response time in a text file, and these time measurements are later analyzed. The first pa

33、ge uses Automatic Data Binding (ADB). Page contains a GridView control, with paging and sorting allowed. The control is populated with a stored procedure that gets all the records from the database as in Code 1. The s

34、econd page populates a GridView control with the same stored procedure called by the first page, but this time we populate the GridView control in the Page_Load event handler instead of after the Page_preRender event.

35、 The third page uses a custom stored procedure (see Code 2) to query the results. The stored procedure orders the results at the SQL server, and returns only the records that will be shown in the web page. 4. MAIN RE