Why is Alpha so slow?

[cellboy]

Is it just me or do other people find that web-hosted Alpha databases are very slow to view/navigate?

We have a variety of databases hosted on our own server and at Alpha online, and even small databases with simple components seem to take ages to load. Using these pages is like going back to the bad old days of dial up internet access before broadband.

Is there some good practice I am missing or could learn from to improve performance?

Kind regards

David

[Steve Workings]

I'm pretty satisfied with the speed.

Check out the related messages at the bottom of this page for some considerations.

[peteconway]

Schools out for me on this.

The only contant result I get is inconsistancy. I have been over this subject many times. I have requested it be investigated and have passed on passwords logins etc. Only not to hear back no further on performance variations.

I can tell you though, using dropdown boxes (table based), grid linking and the use of images in data will take it's toll on your response. And it's not due to page build and render time, as editing and adding records takes quite some time even when the next page to display is a simple gird or search field.

Anyhow it's better than the alternative, that is not having it at all.

Peter

[cellboy]

Thanks Peter, that's pretty much my experience too. I find it can take a while for a simple page with just a single record, entry-only component to load.

At least I know it's not just me!

[peteconway]

One more thing.

Make certain you are using the latest WAS, there was a massive difference in speed accessing by FireFox (5 seconds) V IE (25 seconds) and Lenny made some changes about 3 months ago.

Peter

[cellboy]

I don't notice any difference between our server hosted applications and those that ALpha online,which are promised to be hosted with the latest version... Also, not sure I'm quite following your point. Are you saying it is better to use Firefox than IE in conjunction with Alpha web applications?

[peteconway]

Try this.

What I was getting at is - A5V7 processes/renders differently to IE. It seems when A5v7 detects what browser is accessing it, it then performs the task. Some months back I asked Lenny "Why did it take 4 seconds to login with a password in FF and 18 seconds with IE. He told me there was a problem and would fix it, after some days he did and it was a major win for us all in my view.

One of the most obvious things the two show up is the way the navigation is displayed between the two, the processing differences aren't quite so obvious, but they are there.

Try this, open both browsers, arrange so they are side by side, use the same table for say 5 minutes in each browsers one ofter the other and visa-versa as quick as possible, and observe and you let me what you see.


I know what I see on browsers on AlohaFiveOnline.

Peter

[CALocklin]

The WAS can be very, very fast. Unfortunately, not with web components. I have one page that can display about 9000 records (5200 in the form itself and the rest in drop-downs) in ~15 seconds on a good cable connection. Much of that is download time because the resulting page is something like 700K. Trying to show that many records with a web component will probably cause it to just give up and quit.

If you are willing to forego the web components, either in total or on specific pages, you can get some huge speed increases.

[cellboy]

That sounds interesting, how can you display records without a web component?

[CALocklin]

By hand coding with Xbasic and HTML. This is basically the same as coding a web page with something like PHP or ColdFusion (if anyone still uses that) except the language is different.

Of course, hand coding means you lose the development speed of web components so you have to decide which is more important - development speed or response speed/capability for the user. I've built two websites where the user insisted on displaying 500 or more records on one page. Web components couldn't even do it - at least not at that time. You can see a sample of one of them at http://www.trakitsp.com/inside. This was my test site and contains old data that is no longer valid. (No guarantees how much longer this site will remain available.) Log in to the San Diego page as user "sd" and password "test". Select the first "Type of Business" and it will find about 1200 records then display only the first 500. (Go ahead and play with other search combinations.) There is no other navigation available to see the rest of the records because of a marketing issue - the company is selling the list and only wants the user to be able to get a maximum of 500 records at a time. If they need to see other records, they have to change their search criteria.

Hand coding means:
- You must be familiar with both Xbasic and HTML.
- You need to learn to combine the Xbasic and HTML on one page. This really doesn't take long to learn. It seems really complicated/confusing at first but it turns out to be really simple and I basically had it figured out in the first hour or so.
- JavaScript can be used to make the page more user friendly but isn't required. (I've used very, very little JavaScript and none on the sample site listed above.)
- If future maintenance is a concern, most A5 developers won't be familiar with it so your customer will be more limited as to which other developers will be able to take over should something happen to you. (I only know of a few other developers who are comfortable with hand coding web pages. There may be more but I don't know who they are.)
- One side benefit - I'm able to build web pages that don't require "publishing". I can just FTP them to the site. This has been a great benefit for the generic app I built that will ultimately, I hope, be used by over 50 companies. I was even able to build an A5 routine that simply FTPs any updated pages to each website - just select the page that was updated and let the routine loop through the site list and FTP the page(s). This is much faster than publishing it 50 different times. The pages can be FTPed to any site as long as the last level of the path between the pages and the data are the same. For example, the "xxxx" can be anything as long as the rest looks like: xxxx\htdocs\<pages> and xxxx\trdata\<tables>

Personally, I think hand coding also gives you more versatility. For example, the test site listed above actually changes the page appearance and the search results depending on whether the user logs in as a Library, Full user, or restricted user. The A5w page is the same but what is displayed to the user changes based on the login. In fact, if the user is a "library" user, the results page is restricted so it isn't possible to highlight the results page in order to cut and paste it. (At least, not with today's most common browsers.) All this requires is a few simple IF .... END IF statements in the page with the appropriate HTML code between them.

FYI: Building my first navigation controls for a "grid" (table) was probably the toughest thing I've done so far. However, having done it once, doing it again was far, far easier. The big problem was figuring out the requirements for the process.

[Steve Bovino]

Cal:

I visted your site. It is very clean and fast. I was intrigued by your description of hand coding. Could you supply a sample of how one would utilize HTML and Xbasic to populate a page. I may have an upcoming application that might benifit from this approach.

Steve

[JerryBrightbill]

A number of comments on web page speed. First, after considerable testing, there is little speed difference between browsers. In some cases, Firefox is slightly quicker than IE, in others Opera may be slightly quicker.

Most of the speed impacts come from about 5 sources. First, there is the initial time to construct and populate the page. In a component, currently the HTML is not prebuilt, but is built on demand. Unless the page is very complex, this is actually quite fast. However, the code saved in the component file must be loaded into memory to build the HTML and the time to load the file is noticable. There is also an speed impact to load the data into the component code. Cal's method reduces this time as the Page HTML is prebuilt and no configuation (component) file is being opened. Data must still be pulled from a file and populated into the HTML, so the speed difference there isn't much.

One consideration missed by many developers it that a component allows building a very complex page easily. You can build grids with search parts and detail sections, dropdowns, lookups, and other constructions in a few minutes. Hand coding such a level of complexity is very difficult, very time consuming, and therefore rarely done. The result is that hand coded page HTML is typically much less complex than the resulting source on a page built with a component. Therefore, it will appear the the "component" is the cause of the slowdown, when in fact much of the hit comes from the amount and complexity of the HTML created in the complex construction.

The second speed hit is the time to tranmit the page across a network. This is dependent on the size of the download ( the page size) and the speed on the network. It doesn't matter how the page was built, this impact affects all pages equally.

The third impact is the time to render the page in the browser. This is actually a very small impact, but again is primarily caused by the size of the page. A secondary impact here is the "quality" of the generated HTML and related files like CSS and JvaScript files. If these have errors, or are written with non-standard or incorrect tags (a common situation in hand coded pages), IE may be slightly faster than a more strict browser like Firefox. The page complexity can also slow the rendering.

The fourth impact is the time to submit the page. This is the time to transmit all of the request data back to the server. This impact comes from the amount of data being transmitted and the once again, the network speed. Some pages that appear simple in fact send back considerable data. For example, a component uses a hidden field with the original field values for all input fields on a page. This is part of the "Optimistic Record Locking" used to track data clashes. If there are many fields, such as a long grid, this hidden field can get very large. It has to be part of the transmitted data. This is almost never done on a handcoded page, and therefore the data transmiited is much less, but changed data on the server can get overwritten.

If the page being submitted is a dialog or essentially view only, there is no difference between a handcode page and a component built page.

The fifth impact is the time needed by the server to take the submitted data and save it. In a handcoded page, there may be some logic, but it usually isn't complex. The component allows complex validation code, data formatting, and other important actions that take time. Actions a developer may not write into a handcoded page.

As you can see, the main differences between a component built construction and a hard coded structure come from loading the component file on the server, building more complex HTML, "Optimistic Record Locking", and the more complex code to validate data.

If you want to handcode a page as Cal suggests, there are a few steps. First, you have to create the complete page HTML. Next, you have to write xbasic to put on the page to obtain data from a file or files to show on the page. A simple way to do this is to populate a variable using something like

dim p_fld[1] as p
p_fld.initialize_from_table(tbl_name,tbl_filter)

Then on the page, you would use <%a5 %> tags to place the value of the variable in the desired field

<input name="vid" type="hidden" id="vid" value="<%a5 ?p_fld[1].visit_id %>" />

Of course, when you submit the page, you now have to write xbasic on the page to trap the submission, validate all of the values, and save them back into the correct table. All of this xbasic coding is complex and can take many hours to get correct.

The questions a developer has to ask are, do I have the skills to write xbasic to handle these demands, and do I have the time. The component already has all of that work done for you.

[Pat Bremkamp]

Jerry's "considerations" actually contain a lot of information that will help to speed up the WAS for the user.

1. Create a heading that is html or uses a minimum of Xbasic. In my case, I use Xbasic to load the name of the help page, but otherwise, it's just a graphic with a few buttons. Use A5Include() to load this just under the <head> tag, but before the Xbasic that computes the html, and the heading will appear very quickly. This doesn't make the page faster overall, but the user sees the heading right away, so it seems faster.

2. If you use gridlinkers, try to make the parent read only. If you need to edit the header, include a link to a separate page for the editing.

3. I use dialog components for all my entry screens. The events give you a great deal of control using Xbasic, and they are fast.

4. Use a navigation component that doesn't use the little graphic arrows (or remove them) to indicate that the menu cascades. These are, for example, casover.png. Selwyn says he can't see any delay using them, but I see a very noticable delay...It takes several seconds for the arrows to appear. Of course, I use an old PIII computer, so it makes all the delays more noticeable.

5. If you have a lot of optional data in a record, consider splitting it into two parts. For example, in my people and company records, I use a short basic entry screen for the data that is ususally needed, and made a second screen for optional stuff like ship to, bill to, and remit to addresses.

If you'd like to see my site, log on to mindkicks.alphafiveonline.com/index.a5w You'll see that all the delay is due to the arrows on the navigation component!

login alpha
password sports

or
login lenny (sorry Lenny!)
password lenny

Pat

[CALocklin]

Jerry's comments were very enlightening. I think some of that info should go in the Help file under something like "Optimizing Web Pages". (Maybe it's there - I didn't check.)

I hope nobody read my post as somehow suggesting that hand coding was better. It has it's place but can't compete with components for ease and speed of development. Hand coding requires that you be very comfortable using xbasic (most A5 users aren't) and with HTML (again, most a5 users aren't).

Also, Jerry's comments about building a complex page taking a lot of time are also correct. However, I'd also say that adding those features, although always more time consuming, is much, much, much more time consuming the first time around. Once you've figured out how to build navigation buttons, drop-downs, etc. it's much easier the next time - but still more time consuming than with components. This is one reason I would not recommend this method for a "one-time" developer who will probably only build one major project. Since I build apps for many companies, I can re-use functions and features that were originally worked out on someone else's application. For example, I have a rather extensive routine that allows users to enter dates in web pages like "515" and the resulting date will be 05/15/<current year>; however, if they type 115 it will return a "can't figure this one out" warning because it could be 11/5 or 1/15. Now that this routine is done, I can just copy it to another app.

Jerry also said, "Of course, when you submit the page, you now have to write xbasic on the page to trap the submission, validate all of the values, and save them back into the correct table. All of this xbasic coding is complex and can take many hours to get correct." However, he sorto' skipped a step - if the values don't validate, you have to go back to the original page, adding an error message, so the user can correct it. Also, let me emphasize the "validate all the values" - essentially this means you have to build all the usual "field rules" into an xbasic routine to check them and issue the appropriate error messages when something is wrong. Unless you are very comfortable with xbasic and use it on a regular basis, the task can seem overwhelming.

If you really need the speed or really need to display a huge number of records on one page, hand coding may be the answer. However, for most users, web components are the way to go.

[Peter.Greulich]

J
If you really need the speed or really need to display a huge number of records on one page, hand coding may be the answer. However, for most users, web components are the way to go.

So will this issue be moot, once Alpha implements AJAX?