Performance Issues?

[seidel1]

I am have some significant performance issues. The DB I have only has about 2000 records, yet getting a page back from our server takes minutes, if it comes back at all. If I work on the server directly, I get the same response.

Initially I thought it was a server issue, however, our IT folks looked at it and determined that there are no issues, with the server, the firewall or our bandwidth, which leaves A5. Where can I read up on configuring A5, and how can I troubleshoot this problem?

THanks in advance.

Jim

[seidel1]

RE: Performance Issues?

Additional Information -

Some of my Grids had the Control Type as TextBox. Initially that worked, but I noticed, that the pages I was asking for displayed slower and slower, to the point where they would not display at all. If I changed the Control type to Label, the pages would appear alittle faster.

I also receive messages saying

Sript:UI_DLG_BOX:Line:25 live_preview(lv) out of memory.

I receive similar messages identifying a different line, than I typically get an Unhandled Exception Error and A5 Shuts Down. Thanks in advance

[Selwyn Rabins]

RE: Performance Issues?

we need to see your pages and components here so that we can test them on our machines.

we have tested the grid components against tables with over 500,000 records and have been very happy with the performance.

[Selwyn Rabins]

RE: Performance Issues?

I have received your files, and have started looking at them.


A number of things popped up immediately.


1. On some of your pages, if you switch to source view, you will see that a component is being loaded and not used. In other words, you have orphan components on your page.
This is very bad. It means that you are taking the time to compute the component, but then NOT displaying the resulting HTML. So the time taken to compute the HTML is completely wasted. -- You probably ended up with orphaned components because you deleted the placeholders for the output on the Wysywig view, but did not go to the source view and delete the code that loaded the component.

2. One of your grids displayed 200 rows of data. The more rows you display, the slow it is. Why do you need to display 200 rows at once? The whole point of having paging logic in the grid is so that you can display just a few rows at once. To make matters worse, the grid with 200 rows had several dropdown boxes. Dropdown boxes are expensive because for each row in the grid, A5 has to compute what the selected value is.

Once I set the number of rows to 20 (a more reasonable number in my opinion), and deleted the orphaned components, the performance improved substantially.

[seidel1]

RE: Performance Issues?

Thanks -

"1. On some of your pages, if you switch to source view, you will see that a component is being loaded and not used. In other words, you have orphan components on your page."

How do I detect this, I have been spending 100% of my time in the preview and live preview tabs. If I click on HTML, than what am I looking for? (is there any documentation on this?)

"2. One of your grids displayed 200 rows of data. The more rows you display, the slow it is. Why do you need to display 200 rows at once? The whole point of having paging logic in the grid is so that you can display just a few rows at once. To make matters worse, the grid with 200 rows had several dropdown boxes. Dropdown boxes are expensive because for each row in the grid, A5 has to compute what the selected value is."

I caught this as well. But because I asked A5 to suppress the empty rows, I assumed, it would not take resources unless the data was there, i.e. I ask it to process 200 rows, but it it needed 20, it only processed 20.

Once I set the number of rows to 20 (a more reasonable number in my opinion), and deleted the orphaned components, the performance improved substantially.

[[email protected]]

RE: Performance Issues?

I have a grid hooked to a 100,000 record table and accessing it over the net, the performance is just like I was sitting in front of the server. Very impressive.

Bill Belanger

[seidel1]

RE: Performance Issues?

Bill -

I am confident A5 will do what we want, I just need to understand why what we are doing so far is so slow. Selwyn has pointed out some things that I will try tomorrow and I am also looking at our server environment.

Base on your success with 100,000 records, can you tell me how many tables you are using, and are they all linked? Also, if you know, what is your server size/workload and your bandwidth?

Thanks in advance for the help.

[[email protected]]

RE: Performance Issues?

I'm just playing so far and I have only one table. The server is hooked to a DSL line with upload of 384k. The computer I accessed it with was also DSL with download of 1 meg, all max speeds of course. I say it was impressive becasue I dd the same thing with Filemaker and it was much slower. Don't think I can really help solve your problem becasue I'm new to Alpha.

Bill Belanger

[seidel1]

RE: Performance Issues?

no problem, thanks. I have a similar server situation, upload of 384 on a static IP, and I am accessing it via Cable modem, with greater than 384. THe server is dedicated, so we are thinking its not the server but rather the pages (code). I'll keep the thread posted as to our improvements.

[seidel1]

RE: Performance Issues?

Selwyn, Thanks I will definetely recreate the A5W pages. But that begs some additional questions:

Q1) Is there an efficient or inefficient way to create a grid, or if a grid works is it assumed to be efficient?

A1) The more stuff you put on the grid, the more work that a5 has to do to compute the html. Its as simple as that.
So, if a grid has 20 rows, it will take longer than a grid that has 10 rows. If a grid has 20 fields, it will take longer than a grid that has 10 fields.
If a grid uses combo boxes, or radio buttons etc, it will take longer than a grid that has just textboxes because the choices in the combo box have to be computed, and then for each row, the selected value in the combo box has to be computed.

so in summary, the time take is in direct proportion to the complexity. dropdownboxes are more complex than textboxes. editable grids are more complex than read only grids.

Q2) Why do some grids seem very resource intensive from a creation/edit perspective? (In my files that would be siteteater and sitesensors), and does that overhead transfer over to slower WAS performance?

A2) I would have to go back to look at the components and see what they have on them. I don't have your files in front of me know.
You can find out for yourself by creating a simple readonly grid, and the gradually adding complexity. see what seems to cause a problem.

Q3) Where is the most efficient place to put in formatting for a grid? In the grid style, or in the specific fields properties (inline style) or does it matter?

A3) it shouldn't make much difference, but if you put it in the stylesheet then the style for a table cell for example is set with a command like "TD class=""stylename"" "

if you put it in line then the html becomes

"TD class=""stylename"" style=""inlinestyle"" "

so, in the second case there is more html to transmit to the browser. I am not sure that you would notice the difference though.

Q4) When I insert a grid into a page, it automatically places the 5 components (data, search, detail...) If I don't need some of those, i.e. search, do I improve performance by deleting the unused components? And If I delete the unused component, do I need to go in and manually remove the added HTML?

A4) You don't improve performance by deleting the placeholders.

I am confused by your use of the word 'components' in the question. Do you mean 'parts'.

For example, when you place a Grid component on a page, the page shows several different placeholders for the output from the different 'parts' of the component.

these parts include the Grid, the Search, the DetailView, the Echo and the UpdateErrors.

deleting the placeholders for the parts has NO IMPACT on performance.

But if you delete all of the placeholders, remember that you have not deleted the component itself. The code for the component is only visible in the "HEAD" section.

Q5) Is using Grid Linker more efficient than calling another page from a single grid and than editing it?

No. it would be slower because the gridlinker displays two or more components on the same page. but it gives you lots of built in features - like referential integrity.
for example, if you have OrderHeader====""OrderItems, and you enter a new record into OrderItems, the grid linker will make sure that the invoiceNumber that is entered into the OrderItems grid matches the current INvoiceNumber in the OrderHeader grid.

If you link from one page to another, then it will be faster because you only have on component per page. But you would have to program the referential integrity yourself.

Q6) If I want to post 2-3 seperate grids with individual filter criteria to an A5W page, is there anything I need to look out for?

A6) No. however remember: the more components on a page, the slower the page will load.