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 4

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

Impact of Hardware—Single vs. Dual CPU
The difference in performance between single and dual CPU machines is was so small in initial tests with the Delphi and VC++ objects as to be insignificant. The objects written in Delphi ran to successful completion of 500 threads on the single CPU machine, whereas the same test failed predictably on a dual CPU box.

The pattern of failure pointed to a resource leak, as memory utilization for the instance of dllhost.exe continued to climb while the test was in process. However, once the test subsided the memory used by the dllhost.exe instance returned to the baseline. The VB objects produced a similar pattern in memory consumption, though at a slower rate (most likely due to the 10 threads per CPU limit for STA objects). 



Note: I suspect that the problem is related to ADO, as the VC++ objects coded to the ODBC API exhibited no growth in memory usage.

Thread Count

Fixed Accounts

Dual CPU

Fixed Accounts

Single CPU

Random Accounts

Dual CPU

Random Accounts

Single CPU

50

53.422

56.341

31.547

47.157

100

105.750

113.554

61.156

88.257

150

160.937

166.680

97.688

133.221

200

211.000

219.686

109.422

179.288

250

265.859

279.222

133.828

221.909

300

320.031

342.473

164.344

266.473

350

372.469

395.649

189.954

307.813

400

426.297

464.268

212.406

347.110

450

468.516

556.441

238.578

395.038

500

516.265

628.644

265.375

434.865

Table 5 - VB w/ ADO (time in seconds)

Impact of DBMS—SQL Server vs. Oracle
It should come as no surprise that performance with SQL Server is much better than with Oracle. The difference in behavior is primarily due to the better support that Microsoft products have for OLE transactions, which is a Microsoft standard.

Note that this document is focused on the results of benchmarking distributed transactions. However, I feel that I must point out that Oracle actually performed better in the same test environment than SQL Server when transactions were not managed by DTC. When both were put through a 14 hour endurance test, the Oracle test processed a little over 400,000 more method calls in the same time frame. This equates to 2,000,000 more rows inserted, with a proportional number of additional update, delete and select statements processed.

The performance of Oracle with MTS / COM+ could be better, though at least the stability is improved under COM+. The gradual leak of Oracle sessions that has been an on-going problem under MTS still occurs, though not as rapidly as with MTS on NT4. A number of other factors work to improve this, such as MDAC 2.5 and patches to DTC.

However, sustained operation at high load levels will still eventually lead to all Oracle sessions being held open but not being reused (marked 'INACTIVE' in v$session). This problem appears to be related to interaction between connection pooling and the Microsoft Distributed Transaction Coordinator; the problem is exaggerated by JIT activation.

Thread Count

SQL Server

Fixed Accounts

Oracle

Fixed Accounts

50

53.422

183.609

100

105.750

302.328

150

160.937

441.141

200

211.000

584.016

250

265.859

722.968

300

320.031

902.438

350

372.469

1071.921

400

426.297

1188.797

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

We've learned a few things about performance and scalability of the middle-tier components, confirming some theories while disproving others. We have also debunked some of the popular myths surrounding MTS and the doubts of noted authorities about the potential benefits of object pooling. Now it is time to practice what has been learned about optimizing middle-tier performance with pooled objects.

I recommend that you start with the Sample Bank application in the Platform SDK, as it is fairly easy to get up and running. Before implementing real-world solutions however, I also think you should take the time to explore the sample source code included with the Windows DNA Performance toolkit.

Good luck!





Michael D. Long is a Senior Developer with Hampton-Tilley Associates. He is a frequent contributor to the newsgroups related to MTS and enterprise development, and often finds it difficult to simply accept common knowledge about these technologies. He is constantly looking to develop a better understanding of how to improve scalability, performance, and code maintainability.
Jamie Burkholder is a Developer with HTA, and provided highly valuable assistance with modifying the OPBank client, writing the Delphi objects used for the test, and executing the tests. His technical skills are as deep as they are broad, and Jamie is constantly looking for new challenges.
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