You will likely want to achieve a "good" performance with your IntraWeb application.

How to achieve a "good" performance

IntraWeb itself is continuously optimized by our developers to allow the best performance possible. You have to be aware of a couple of items though, so that you application really works "fast".

General

Memory

Database

Testing

To determine the performance of web applications there exist a couple of different approaches. It is important though, to test properly.  When testing you have to be aware of a few items that can negatively impact your tests.

Testing with IW Server and web browser on the same machine

This is certainly the most intuitive test procedure, as you just need to hit F9 in Delphi (or F5 in Visual Studio), the IW server starts and you can test your application immediately by opening a web browser and entering the start URL. This test is not really meaningful performance wise though.

  1. When using Internet Explorer, the first page will render quickly. However, when you click on a button or a link from the first page, Internet Explorer will then load extra libraries and cause a delay. This delay is caused by the way how Internet Explorer works, and not the IntraWeb application. As you move to successive pages, you will notice that this delay no longer exists - the required libraries are already loaded then. 
  2. When using a browser on the same machine as the server the network is forced to use the "loopback" address. The loop-back address generally provides good performance however sometimes will introduce delays into the transfer of data.
  3. When using a browser on the same machine as the server, the browser, network and application all compete for CPU, disk and memory at the same time. Most browsers are quite CPU and memory intensive, and thus negatively impact the server and your results.
  4. When using Netscape and running your application from Delphi, the Delphi debugger hooks and Netscape conflict. Often you will have to task switch from the browser to the application to "unstick" the local network.
  5. Anytime you run your server from within Delphi or Visual Studio .NET, their debuggers are active. The debugger not only consumes memory and CPU, but can also slow down the execution of your application. Under normal circumstances, this is perfectly acceptable, however keep this in mind if you are testing performance.
  6. The first time you execute an ISAPI based application the web server must load the DLL and this will cause for a delay.