Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Effective Windows DNA Applications: Maximizing Performance with Object Pooling : Page 3

Windows Distributed interNet Application (DNA) is an architecture for building n-tiered applications for the Microsoft Windows platform, based on the Microsoft Component Object Model (COM). Developers can generally choose the language in which they are most comfortable for building components, though you should be aware that not all languages are created equal. In this article we discuss the performance implications of development languages, as well as the impact of the database and the hardware on the overall performance and scalability of your application.


advertisement

Initial Test Results—Object Pooling vs. JIT Activation
The tests are based on the Sample Bank projects included with the Platform SDK. Be aware that the Account.VC source leaks connections when utilizing connection pooling. I have provided Microsoft Support with the modified source code that corrects this behavior, with the expectation that the Platform SDK sample will be updated.

For the initial tests I configured the OPBank Client to run 20 iterations of the MoveMoney transaction, with the default setting of random accounts selected. All of the objects were configured with for a minimum of 20 and a maximum of 50. I chose 100 thread increments, as I was anxious to see just how far object pooling could go; I was pleasantly surprised to see that the behavior exceeded my expectations. Table 1 shows the results of the initial round of testing.

 



Thread Count

Pooled Objects w/ Constructed Connections

Pooled Objects w/ Connection Pooling

JIT Activation w/ Connection Pooling

100

36.390

78.891

70.281

200

39.953

136.109

149.484

300

58.016

159.756

** failed **

400

76.860

195.766

- not tested -

500

92.750

269.125

- not tested -

Table 1: Object Pooling vs. JIT Activation (time in seconds)

Notes About the Initial Test Results—Pooled Objects with Constructed Connections.
Clearly this technique provides better throughput than either alternative. I have had a long-standing theory that it is frequently better to delay creation of extra resources when the latency is low. By allowing unchecked growth (of any object) the OS is overwhelmed and the system responsiveness degrades to an unacceptable level.

Pooled Objects with Connection Pooling
I expected a difference in behavior, but to be honest the actual discrepancy between constructed and pooled connections is far greater than anticipated.

JIT Activation with Connection Pooling
The similarity in performance with Pooled Objects w/ Connection Pooling is the first point of real interest, as it demonstrates that the interaction with the connection pool is a bottleneck. The second important point to note about this last test is the failure under load, which resulted in DTC hanging while attempting to abort all 301 transactions (300 attempting to update account information and 1 recording the next receipt value). These results provide more evidence to support my long-standing comments about the ineffectiveness of the connection pooling algorithm, though it took COM+ and an object pooling test case to demonstrate the impact of JITA. This is the first case where MTS / SQL Server produced a fault that is in-line with the issue afflicting Oracle. This behavior is 100% reproducible, and the test case has been furnished to Microsoft Support in order that the DTC issue can be resolved.

Impact of the 'Use Random Accounts' Setting
As you have probably noted, there is a glaring 8.6 seconds discrepancy in the total times at the 100 thread count level in the two tests using connection pooling. Each iteration will produce different results, as the contention varies from one test to another based on the account numbers generated.

A Note Regarding MTS vs. COM+
As MTS cannot implement object pooling, the current performance limitations cannot be resolved without building an infrastructure similar to that which Microsoft has delivered with Windows 2000 and COM+ Services. The behavior of MTS is very similar to the characteristics of the JIT Activation with Connection Pooling test, though the results will not be identical.

Without investing a significant amount of resources in building a proprietary infrastructure with a limited life cycle, there is little hope of dramatically improving the scalability of MTS. Because this course of action is impractical, in my opinion MTS on Windows NT 4.0 is a dead end; the future is with COM+.

Comparing Additional Factors
The scalability and performance characteristics of the Sample Bank application are also impacted by differences in the programming language, hardware platform, and the back-end DBMS. This section discusses the response times resulting from changes in each of these three factors.

All tests were driven by the OPBank client, with 20 iterations at the indicated thread count and test type (fixed vs. random accounts). The timing results based on fixed accounts should be weighted more heavily when comparing behavior, as the use of random accounts introduces statistically significant variances. The total number of distributed transactions performed is 1,010 for every 50 threads (for a total of 10,100 at 500 threads).

Note: the random accounts setting more closely simulates a typical real-world environment, but my ultimate goal in testing was to determine the throughput potential when data access is highly serialized. By determining how the DBMS handles contention I can make a better estimate of the behavior that can be expected in large scale DNA applications.

Impact of Language—VB, Delphi, and VC++
The test suite was implemented in the two programming languages that our shop uses most heavily (VB and VC++). In addition, Jamie and I had long been discussing the merits of Delphi in middle-tier development and this was an opportune time to put it to the test.

The choice for the data access technology used with each language was due to multiple factors. I selected the ODBC API as the first implementation because it is the technology used by Microsoft in both the recent TPC-C results and the Doculabs benchmark that was discussed at the Windows DNA 2000 Readiness Conference in Denver, CO in early March. The focus switched to ADO, not because we felt that it would provide either superior performance, but rather due to its ease of integration in DNA applications and wide acceptance among developers using VB / VBA.

The specific versions of the languages used are:

  • Visual Basic 6.0 Enterprise Edition, Service Pack 3
  • Visual C++ 6.0 Enterprise Edition, Service Pack 3
  • Delphi 5 Enterprise Edition, March 2000 Update

Thread Count

Fixed Accounts

Random Accounts

50

19.297

10.188

100

36.750

18.796

150

54.343

28.047

200

71.078

38.171

250

87.703

45.672

300

106.985

54.765

350

124.250

64.500

400

141.641

74.797

450

159.375

79.860

500

176.844

90.484

Table 2: VC++ w/ ODBC API (time in seconds)

Thread Count

Fixed Accounts

Random Accounts

50

19.797

12.625

100

38.469

23.938

150

56.016

31.812

200

75.781

43.563

250

92.610

56.078

300

119.172

64.906

350

138.516

77.688

400

171.187

88.907

450

---

---

500

---

---

Table 3: Delphi w/ ADO (time in seconds)

Thread Count

Fixed Accounts

Random Accounts

50

53.422

31.547

100

105.750

61.156

150

160.937

97.688

200

211.000

109.422

250

265.859

133.828

300

320.031

164.344

350

372.469

189.954

400

426.297

212.406

450

468.516

238.578

500

516.265

265.375

Table 4: VB w/ ADO (time in seconds)

Figure 1 - Language Comparison  (time in seconds)





Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date