Speed issues of WAS

[George Corder]

I have a server that I have installed my copy of WAS onto with the following specs:
HP ML350 dual 3.06Ghz Xeon processors, 2GB ram, (3)SCSI drives RAID-5, Windows 2000 Server SP4.

We use this server in our LAN environment only. 100mb nics and fiber to connect adjacent office building with 100mb ability once there.

Application #1 has 418kb dbf file size with 1568 records in it. No relations, tabs etc. A simple flat file.
Application #2 has 70kb dbf file size with 645 records in it. Again, no relationships, tabs or fancy forms/html pages.

Could someone tell me if it is the normal performance to have a 15 second average delay in navigating to the next screenfull of data on a grid layout while logged on with no other users on the network? I feel that this is too long given the size of the tables.

I have searched the 2 WAS forums for this but the topics get into "rebooting the server" for a fix or to "download the latest patch just uploaded by Alpha".

Is this a Alpha5 WAS related issue which will get better with future development? Could someone that has compared the speed of the WAS vs Data-2-the-Web comment on the performance results?

I really like the interface of WAS in building the apps and would "tuff it out" until v8 or a client/server release if I can be assured that the speed is going to improve. I feel that 4-6 seconds on a page refresh is the norm for user acceptance.

Please share your thoughts.

[JerryBrightbill]

15 seconds is not normal performance, but not unusual either. Actually, many users would consider 4-6 seconds as too slow. There are many factors that affect speed. Data file size is typically not one of them.

First, the server must build the page HTML code. That speed is affected by the processor (your�s should be fast), the speed of the server architecture (the WAS) and the complexity of the page. There is constant work going on to increase the speed of the WAS server and the code to build the page. As far as WAS vs Data-2-the-Web, the only difference is the data source as both use essentially the same code to build the page. In the Alpha WAS, there was a change made in a later build to improve the speed of large pages. You should be running the latest build for best performance.

The biggest impact on construction speed is the complexity of your pages. A very simple view only page may take less than 1/2 second to construct. A very complex edit page with grid linkers, large grids with lots of data, and multiple dropdowns that must be populated may take much longer. I have seen some very complex pages take up to 10 seconds or more to build. This speed change is not necessarily linear. Sometimes just removing a few dropdowns, or a few rows, or a few fields, can have dramatic speed increases. For example, the break point in a grid where speed begins to drop off is about 10 rows.

The second speed hit is sending the finished HTML to the client computer. This is essentially a text file download, so it is dependent on the speed of the network (not usually a problem on a local network) and the size of the file. Again, a large, complex page may create a large file to download. This file is downloaded on every page request. A rule of thumb used by some web designers is that the final HTML source code for a page should not be more than 64K. I have seen some complex pages with source code sizes over 250K. They are very slow to transmit.

The third speed hit is the time to render the page on the client computer. In almost any modern computer, that should be fast, even with large, complex pages.

All of these impacts affect any web product. Some are slightly faster or slower, but the main speed impact in any web project is the complexity of the page design. I once saw a page built in a popular competing product take almost a minute to render, simply because of the page design.

There are a couple methods to find the source of any slowdown. First, publish the project to a folder on the development computer and run it there as localhost. You can see the same effect using LivePreview. If the page is fast here, but slow when accessed from another computer, you may have a network issue. However, it is more likely that the speed issue will show running locally. Try simplifying your pages. Run each component in the browser preview to see if any are significantly slower than others. Try to limit the amount of data on any page. A common technique (also used on the desktop) is to make a grid view only, and then either use an editable detail view or link to another page with editable detail.

The main goal is to reduce the size of the page. This will dramatically impact speed in every area. It is better to use multiple pages, rather than putting everything on a single page.

[George Corder]

Thank you Jerry. I have one page that is slow set to 100 records per page. I have tested this with varying row counts and get:
20 records ~ 5 seconds to load from page to page
50 records ~ 9 sec
100 records ~ 16 sec


Thanks for the rundown. I will test with the localhost.

[Peter.Greulich]

George,

Jerry, with his great expertise, is explaining the processes the browser/server must go through to render a WAS page, thus, in part, explaining the slowness issue. Personally, I have a simple mind about such things. For example, when I enter a search in Google, I get instant results; no waiting. Similarly, my Gmail account runs just noticably less than desktop speeds; but it's pretty fast. Nice! Of course, Google employs AJAX and probably other techniques that make it whiz-banger fast. When ALPHA releases ver. 8 in the future, they say they will employ AJAX. Thus, it should also be very fast. In the mean time, one has to endure the slowness, I suppose.

[George Corder]

Right Peter. I guess with Google's resources development comes at a much faster pace. I thought about delving into the PHP/MySQL path, but I know that Alpha is working on newer versions and better capabilities for the near future and I would much better work in the interface that they have built for us.

[JerryBrightbill]

Actually, nearly any web product goes through the same process to create, send, and render a page, regardless of the server technology or the structure of the database. Google does use some interesting methods, but their main advantage is computing power, and the fact they keep the amount of data on a page to a minimum. They have some very fast servers that are optimized just for their application. In Alpha, each page is essentially a custom page built on demand, which does have a speed impact. Google is not a fair comparison.