Using VB 6 Web-Classes to drive web sites. Some practical aspects.

Alternative presentation of this study.

The development of the web has left many web developers and programmers frustrated. Despite the promises web sites that blend great presentation, persistent data storage and smart computation are rare and disappointing. Considerable efforts are being made to provide better technology. One of these is the IIS-application also known as WebClasses provided in Visual Basic version 6.

Seasoned developers have learned to their cost that new technologies often have shortcomings that make them unusable or at least very difficult. A pathfinder project was undertaken to establish whether the IIS-application technology seems worth pursuing, and to find where special attention is needed. This study includes things like:

1. Why use VB 6 to drive a web site?
2. The importance of process isolation.
3. Testing with many users
4. Remote deployment
5. Design and Improvement issues
6. Worth pursuing?

The project revealed how easy some work was and found unexpected difficulties.

What is a Pathfinder Project?
It is designed to help establish guidelines for the ensuing production project, or to show that no such project should be attempted.

 

Why use VB6?

An active community is testing the IIS-application technology. Different things drive them. Here are some of the things that motivate me.

1. I can hide the code. The web is famous for being an open source of design and algorithm ideas. This has been vital in the rapid development. Some programmers are unhappy with that. Client side script, Java classes (which can be decompiled) and even server side script lack adequate security. What give away years of development for free?
2. Doability. Some jobs need classes, good exception handling and high productivity. VB 6 offers these.
3. Comfort. VB is a language that is comfortable. It has proved fairly easy to use, It promises to endure, There are a lot of programmers who use it these days (so maintenance is easier), Existing code can be re-used.
4. Task Separation. VB (and the environment it works in) can be used to help separate page design, different programming tasks and database design.
5. Extensibility. VB (and the environment it works in) has been evolved to include things like Interface based programming, isolation, threading support and improving developer environment. It promises to continue this trend with for example better "event" handling for COM objects and better deployment of DLL's.

Against it's use weigh some worthy arguments:

1. IIS-applications cannot be hosted by your common ISP. The most likely scenario at present is a server of your own on the web.
2. Knowledge of a wide range of areas is needed. These encompass COM issues, how the server machine runs, how HTML / ASP work and administration (which programmers often hate!!)
3. Some serious sites (i.e. VBLIVE site, Fitch and Mather, the DNA tuning Bank sample) have been given a lot of attention to make them perform, especially for multiple users. In the near future those who use the technology must expect to expend similar effort. (It is usual for early adopters to find a better solution is freely available to all comers in a later iteration. That can really hurt! Expect it here.)
4. Many applications are better served by HTML, Front Page type ASP and Desktop Programs (and their derivatives). Where those tools work they are a great choice.

These are a few of the issues. Before leaping into this technology a good look at these (and the others that effect you) could save pain later.

Testing

Testing web sites for syntax, appearance, browser compatibility... is one thing. Extending tests to server performance under heavy loads takes many web developers into new territory. The advice of more experienced testers was to use a tool from Microsoft called Web Stress Tool (formerly Homer) .

Web Stress Tool (formerly Homer) is a freely available tool a version of which is planned to ship with IIS 5. We had a look at it and were very pleased by what we saw:

• The product was developed by web stress testers to be easy to use and to mask the details of what is happening from the user. We found it very easy to set up (in contrast to other tools).
• Web Stress Tool (formerly Homer) runs as a service under NT and can be administered remotely via an ASP page (not tested). You can access the object model and build your own client.
• The product has many features that are best understood by loading it up and testing rather than jawing about it.
• We liked being able to import IIS logs to start our scripts.
• The Jet database was also a great resource when manipulating the results.

This tool took a lot of pain out of the work. Great product. Exceeded our expectations.

What was tested

A simple framed front end was created for the application and the seven content pages were reproduced in three versions:

• Plain HTML
• ASP
• IIS-application

A second version of the ASP variant was produced that used the same classes as the IIS-application

The full application allows data to be persisted into a database and uses that data when performing evaluations which are presented over the web UI. After initial experimentation it was decided to test a part of the smart system that does not make calls to the database.

The tests were not of identical systems. The ASP and WebClass versions make some use of their technologies as they would in an intelligently designed real situation. In particular we tested the Tag Replacement feature of WebClasses.

Tests were run with:

• 1 to 100 users
• Over a LAN
• Over the Internet (limited, bandwidth precludes saturation bombing - high user load)
• Server performance was logged (processor cycles, memory used, ASP queue length...)
• Without other processes running.
• This test exclusively used data already in memory, it did not access the database nor seek to force exceptions (which get logged). In other words the features that use persistent storage are not reported here.
• Server logging was disabled. (Logging to a flat file was switched on for a test within a test. When logs get large on the same web server machine many processor cycles are eaten!)
• Mean values are used, over 100 data points per run. Means obscure the detailed dynamic behaviour but seem adequate. Detailed dynamic behaviour was monitored for many of the tests but is not presented here.
• Tests were run on a 266MHz PII HP single processor server, running NT 4 and IIS 4 in a clean installation. (Service pack 4 was installed as were various components such as Windows Scripting Host (WSH) with version 5 scripting engines.)

Tests had a very quick user response of less than 9 seconds. This was intentionally harsh. It should be noted that other testers often use a TTT (Time To Think or Think Time) of 60 seconds which would give a much better showing for the technology. (See design suggestion.)

Test results were stored in a Jet database by Web Stress Tool. This database was used through a front end that performed some programmatic manipulation and queries to marshal the underlying data into the required format. Results were plotted and the resulting images processed to an acceptable form.

Results of the tests

Results from the tests were analysed in various ways including graphically as illustrated here.

Examination of the primary graphs reveals what happens as user load increases although no single graph represents the overall quality of the process.

Specific graphs show part of the picture:

Processor saturation illustrates how the WebClass application tested is considerably hungrier for processor cycles than the others. This is exactly what we expect of a smart web site. NOTE: The blip in the HTML graph is where IIS logging was switched on (into a large log file) to observe the effect.

Comparison of items per second against the maximum possible (black line). HTML and ASP shape up well. The WebClass looks good to about 18 users when it's performance drops. NOTE: If real world tests indicate a Time To Think greater than those illustrated the drop off with the WebClass might occur off this graph!

Useful as these graphs are interpretation is needed. So we created a simpler measure.

That simpler answer is a performance rating against number of users. We created a measure that ranges from 10 to -10 where:

• 10 is great
• 5 is acceptable
• on passing zero performance goes unacceptable
• at -10 performance is terrible

Among the contributors to this measure are user response time (TTLB - time to last byte), processor load per user (MHz per user) and a comparison against an ideal server. This simple measure emulated the analysis derived from a close examination of the contributing factors very well.

Results like these can be used in planning and evaluating a campaign to improve performance.

Testing and Design

Although many developers are not yet set up to test and evolve their IIS applications useful work is available:

• The NSTL tests undertaken for Microsoft
• The DNA tuning kit
• The VBLive site, which illustrates one way that the technology can be used was not available when last tested.

One of these (NSTL) illustrates the end result of tuning and the another (DNA tuning) shows one approach to doing the tuning while the VBLive site code illustrates coding used to avoid low performance. They address issues that impact WebClass projects and one specifically focuses on WebClasses.

An approach suggested is to use hardware changes and reconfiguration first to meet requirements. If that does not work programming changes are suggested. (The tuning kit contains more than 20 versions of a banking application written in C, Java and VB.) Data access technology is clearly critical and using powerful computers (multiprocessor, fast drives, cache and RAM memory...) can have large effects. One series of improvements demonstrates about a 15 fold improvement (transactions per second) after a series of changes.

I would guess that most programmers do not have the time to test as much as they like. The following thoughts may help.

1. Use a really thin WebClass. Hand off the processing to other classes quickly. This way you can use those other classes from ASP if that proves to be the best way to go. Gives you a foot in both camps. [This may fit well with developing your own custom parameter handler when you are using tag replacement.]
2. Work hard to control user think and response time. Give the user enough information to make his web site hit worth the trip (and to delay his return with longer Time To Think) and provide client side processing (maybe JavaScript) where appropriate. This can allow a given server to handle several times more users.
3. Pass big chunks of information between your classes. This may not make much difference if your objects are in process but as soon as they go out of process it will pay handsome dividends. UDT's and packing a lot into complex Variant structures are two ways to achieve this. (ByRef parameters are another approach but it feels wrong, in my view.)
4. Log exceptions locally on the server (line numbers and handlers in every routine sounds good) and do not show any exception messages to your users.
5. VB events are not inherently scaleable (today) and problems have been reported. It might be best to avoid events altogether. Custom asynchronous event handlers and MSMQ could be used if you must.
6. The current version of the designer tends to do unexpected things to your ASP/HTML when it processes the pages. I like to keep it out of the picture.
7. It is realistic to separate the code design and page design. This is great even when the same person does both. A brief "product manual" formalises the separation nicely.
8. Think flexible. Deployment, the form of replaceable tags (parameters!!), event handling, xml integration, WebClass performance are all likely to improve. Will your design need a minimum of reworking?
9. Data persistence is important. This should probably be tested in most projects, until you become expert. Make your Access databases SQL ready (avoid keyword clashes...), compare to MSDE, does a MetaBase have a role...
10. Make sure you have dual interfaces. You might want to invoke from script and from compiled code.

Moving On

This study brings home the realities of the bleeding edge. Smart applications consume processor cycles. This is painfully obvious from comparing an HTML web site with a similar WebClass site. The WebClass site is processor bound the HTML site is not. The fact that a major research effort (NSTL) used sixteen 500 MHz processors in four boxes to front end a web site and two similar processors (in one box) to run the database reinforces this conclusion.

In a world where computer memory can be plugged in with little effort we can hope and expect that processor power will go a similar way.

Other approaches are needed if your budget is limited.

When the money and operational staff are available a series of tests will enable an application to run faster by "scaling out". In other words increase the speed and number of drives used, add RAM to a machine, add processors to the boxes, cluster boxes and build a network. That approach is nicely illustrated in the DNA tuning kit.

Another approach is to try out all combinations of all technologies to find what is best. A more practical version of this is to try one change at a time and make an intelligent choice of what to improve next. Again the tuning kit provides an example. They use C, VB and Java for a total of 23 approaches. Once again deep pockets are needed if you go this far!!

For those who have chosen VB and have limited resources (a lot of developers?) the choices are less. The names of the samples in the tuning kit give an idea of what is being done (VBADO, VBADOASP, VBODBC). [I have not examined the samples in detail.] For the VB developer intent on using the technology I guess the following are useful:

• Compare approaches where this makes sense using Web Stress Tool or a similar tool. (No point in coding some stuff in ASP that will not be maintainable!!)
• Learn about some underlying technology hidden by VB (COM, Single Threaded Apartments, User Defined Interfaces...) so that you can write better performing code, and know what not to try (events, custom call-backs, UDI's maybe).
• Be ready to deploy whatever way makes sense (ASP, WebClass...)
• Compare different approaches to persistence. MSDE versus Jet databases for example. There are interesting questions in this area too, like what about using a MetaBase?
• Work to make deployment as painless as possible.

Smart and determined developers can use this technology where the potential gains far outweigh the risks. It is advisable to design flexibly to weather the probable changes during a project (MSWCRUN is being optimised, this could have impacts).

Thanks to:

• DataSoft for hosting the test machine
• Creative Solutions for the server
• The following for various contributions: John Timney, Mike Russel, Richard Borrie, David Miles, Mike Kiss, Rod Drury, Dave Thompson, Matt Odhner and the Web Stress Tool (Homer) Team.
• Microsoft NZ for the Venue, Pizza and Drink
• David White for organising