Iron Speed Designer creates a standard Microsoft .NET application, so in general the application load and scalability issues involved with Microsoft .NET applications also apply to your application. Also note that Iron Speed Designer does not provide a server component; the application server is Microsoft Internet Information Server (IIS), so the load factors affecting the application are determined by Microsoft IIS.
Besides the machine configuration, several factors impact the application load including:
The .NET Framework you are running (e.g., .NET Framework 2.0 versus .NET Framework 3.5)
Stored Procedures vs. Inline SQL queries
Your database: Microsoft Access, Microsoft SQL Server, Oracle or MySQL and which version of the database
Operating system: Microsoft Windows version; 32-bit vs. 64-bit
Security mechanism: Active Directory versus database security
Your database schema and indexing
Your code customizations and their performance
Your system, memory, other applications loaded
In general we have found that the aspect that effects load and scalability are completely related to the system (number of processors) and the amount of memory.
In certain cases, an application built with Iron Speed Designer may run more slowly than anticipated. You can turn on application tracing in your application's Web.config file to see where time is being taken in your application. See the online help about the Web.config file for instructions on how to enable application tracing. There are also instructions in the application's Web.config file itself. You also can enable tracing in Iron Speed Designer:
Sometimes the Display Foreign Key As (DFKA) facility in your application takes longer to retrieve all the records than is desired. You can change this behavior in the Property Sheet for individual filter controls on your application's web pages. Specifically, you can choose "Populate All Values" or "Populate Only Values in Result Set". Select "Populate All Values" to make your application run faster on a page-by-page basis.
If you have too many DFKAs on a page, then you may be better off joining the tables together instead of using the DFKA, because the DFKA facility reads the DFKA value one record at a time instead of using an underlying join. For example, if there are 10 rows from the Orders table that are being shown with the Customer Id and Employee Id being shown as a DFKA, there will be 21 queries performed – one query to retrieve 10 rows from the Orders table, 10 queries to retrieve the DFKA Name for each of the 10 Customer Id’s, and 10 queries to retrieve the DFKA Name for each of the 10 Employee Id’s. When using a table join, these 21 queries can be replaced by just one query. Note that Iron Speed Designer caches often requested information to optimize performance, so the application may not necessarily perform all 21 queries each time the page is displayed. The best-case scenario when using DFKA is 1 query and the worst-case scenario would be 21 queries. When using DFKA reduce your default page size: remember that for each row in a table application will run separate query for each DFKA!
Starting Version 9.1 Iron Speed Designer gives you a choice to use either ROWNUM or triple somersault paging technique for MS SQL Server 2005 and later. In most cases, queries that use ROWNUM pagination execute faster and this technique does not require running a Count(*) query, however in certain cases such as Views without virtual primary key and with several underlying tables joined, using a triple somersault technique could be faster. To change pagination method for a table, change the property in the Data Access Layer:
Sometimes it is better not to count records in the table especially if the table is large. In version 9.1 and later application will run Count(*) query only when any control on the panel tries to get the value of the TotalPages property. Removing or not including such controls allows considerably improved loading for large tables. For example, you may consider not to include total number of pages in the pagination control.
To improve search, filter, and sort performance, index your table by any field you use in these operations. If you have to filter by two fields, create a compound index of these two fields. Refer to Improving Database Performance for additional information about Database performance tuning.
A Search control is usually configured to search through multiple fields using ‘Contains’ or LIKE query. This might be very ineffective on large tables because it does not use indices. You may improve your search by enabling Full Text Search in the database on all the fields you use to search, or alternatively replacing a search control with filter controls. If you have three filters, each of them filters only one field in the database and will be able to use indices to perform the search much faster.
If you have a Foreign Key pointing to a very large table and you have a filter by this Foreign Key on your page consider changing the Filter Control Type to TextBox instead of DropDownList because DropDownList will run a separate query to populate the first 500 records from this large table while TextBox does not require a query on a page load.
Having many DataSources on the page can slow down page load because each DataSource runs separate query(s) to populate data from the database. Make sure you have only those DataSources which you really need and remove all unused ones:
Some pages may be sped up by disabling the Smooth Panel Update feature. This comes at the cost of application users having to guess when the postback or initial load is actually complete because Internet Explorer may indicate that the postback is finished when it really isn't.
Some applications can be improved by making sure that Microsoft IIS caches static images and that Internet Explorer also caches static images.
Some users have reported success using tools such as Cache Right (http://www.port80software.com) and HTTPAnalyzer from IEInspector, which analyzes traffic between the web browser and the server.
Enabling compression in IIS makes page download faster:
When the application is deployed to production consider compressing JavaScript and Style Sheet files:
ApplicationWebFord.js, ApplicationWebUIValidation.js, App_Themes/<Theme Name>/BaseStyles.css
You may use any number of tools for that purpose, for example:
http://refresh-sf.com/yui/; http://developer.yahoo.com/yui/compressor/
You can configure Common HTTP Response Headers to specify page expiration. Consider the following information when you configure the expires response header:
• Content that is updated regularly, such as on a daily or weekly basis, should be configured to expire periodically.
• Content that contains sensitive information that you do not want cached or that is updated very frequently should be configured to expire immediately.
• Content that is not expected to change should be configured to expire in approximately one year.
Use the Internet Information Services (IIS) Manager to configure IIS
As stated in a blog article at http://blog.cloudfour.com/should-i-remove-etags-from-my-headers/
In 2006, Yahoo! published some performance research in which they state “Our experience shows that reducing the number of HTTP requests has the biggest impact on reducing response time and is often the easiest performance improvement to make.” One outcome of that research was a set of recommendations for reducing the number of HTTP requests, and one of those recommendations was to configure your ETags or simply remove them entirely.
So you can download and install the URL Rewrite extension to IIS from http://www.iis.net/downloads/microsoft/url-rewrite and then use a URL outbound rule to remove ETags. With the URL Rewrite extension installed, a rule can be added in the <system.webServer> section of the web.config:
<system.webServer>
…
<rewrite>
<outboundRules>
<rule name="Remove Etag">
<match serverVariable="RESPONSE_ETAG" pattern=".+" />
<action type="Rewrite" />
</rule>
</outboundRules>
</rewrite>
…
</system.webServer>
Improving Database Performance
Windows 2003 Application Performance Suggestions
Running Applications on Multiple Servers