Web server performance problem?

[ab042]

I've been having unexplained problems with my app so I've done a few test to try and figure it out. I need someone else to do some testing please. I can't put my finger on it, but there is a problem with the WebServer getting screwed up. I've tryed this on my local machine and the web server product.

Started with the "Customer_wDetailView.a5w" in WebAppDemo.
I've added 5,000 test records to the existing customer table.
I've created a new DEFAULT tabular, updatable, search grid component with ALL the fields and all the defaults. Search is Last Name, no other changes.

Publish and bring up the new page you created in the "localhost" web server.

Change the RECORDS per page to 100 and select SEARCH. No other changes and if the page comes up at all it takes forever to display it.

If you can get that working bring it up in a few different browsers to simulate multiable users and start doing simple searchs while leaving it at 100 records.

Sometimes the page returns WITHOUT ERROR but the search didn't happen??

It sometimes crash the web service to where you can't even stop it in A5 without a message showing. "The Server was not able to shutdown".

[ab042]

bump :)
Lenny do you have any thought on this its driving me crazy and I'm not sure what to check or do? Is this a possible issue with WAS that your aware of?

[CALocklin]

If you change it to 10-20 records per page does it work correctly?

[ab042]

Yes

We didn't notice the problem until we started testing larger request and more users.

[bowenjohn]

What is the hardware configuration you are using? WAS requires a hefty box,

[ab042]

Its a dell server with I believe 2 gig RAM and it also happens on my noteboook P mobile 1.6 with 1 gig RAM. ITS NOT THE BOX.

If it takes that hefty of a box to access a few hundred records from a few users then there is a major problem.

[ab042]

bump
Alpha: I need to try and figure this out. Any suggestions?

[Lenny Forziati]

If you can give me the steps to reproduce this problem, I can take a closer look. But following the steps in your description above, everything ran just fine for me.

bump
Alpha: I need to try and figure this out. Any suggestions?

[ab042]

Started with the "Customer_wDetailView.a5w" in WebAppDemo. 
I've added 5,000 test records to the existing customer table.
I've created a new DEFAULT tabular, updatable, search grid component with ALL the fields and all the defaults. Search is Last Name, no other changes.
    continue..... (See first msg in thread)

Please, what else do you need from me.
Just create a grid with ALL the fields as I have explained in the first msg.
I am so under the gun on this, I had a meeting today and it didn't go well.

[Lenny Forziati]

Jerry, a 100x21 editable grid is hardly a real-world example of a well-designed web application. You are asking the server to calulate 2100 edit controls all at once, which is a lot of work to do.

I suggest rethinking your application design, web applications require a different approach than desktop apps. But if you really want to have this much on a single page, you can hand-code a page instead of using a grid component to significantly improve the performance. The grid offers a great deal of functionality but the trade-off is the prefoormance penalty.

Started with the "Customer_wDetailView.a5w" in WebAppDemo. 
I've added 5,000 test records to the existing customer table.
I've created a new DEFAULT tabular, updatable, search grid component with ALL the fields and all the defaults. Search is Last Name, no other changes.
    continue..... (See first msg in thread)

Please, what else do you need from me.
Just create a grid with ALL the fields as I have explained in the first msg.
I am so under the gun on this, I had a meeting today and it didn't go well.

[ab042]

Lenny, the question and issue was not concerning a real world application or even a well designed application. It was nothing more than to reproduce a problem with WAS.

I was having unexplained lockups and problems with nothing near 2100 fields and if I would have posted that statement you would have ask me to see if the DEMO had the problem. So I created a very easy to create example of the problem.

As for the 2100 number you could also do a little different calculation and would come up with some very real numbers. For example if you had a form with 8 columns and only showed 20 line items you would hit your 2100 number in 13 users.

Considering 25, 50 or 100+ users or more columns and less line items and you statement below creates real problems.

It goes to the very integrity of a production application.

[CALocklin]

Jerry, I'm afraid you've come up against a limitation of the web components. That's one reason much of my stuff has been hand coded. I can create a page showing 9000 records (5200 displayed and ~4000 in drop-down controls) and it displays in about 12-15 seconds. Most of that time is required to download the 750K html page that is generated.

While I don't recommend most people attempting to view that many records all at once, it is no problem when you hand code the page - and the user has a high speed connection to download the huge page that results. Unfortunately, hand coding also removes the convenience and development speed of the web components but any time you automate something, something else has to give.

Also, this is not a "per user" issue as far as I know. One user trying to show hundreds of records in one web component will see slow load speeds and the whole thing will quit if it's big enough. I don't believe that a second or third user should have any effect on how user number one's page loads. A hand coded page showing 100 records with 6-8 columns of data takes only a second or two to load. Compare that to a web component load time and you will see a huge difference.

If you want to see the results with a hand coded page, go to http://www.trakitsp.com/inside and click on the San Diego link and use 'san' as both the name and password. THIS NAME AND PASSWORD WILL ONLY BE AVAILABLE FOR A COUPLE OF DAYS. Once you get to the search page, click on any basic business type (a type with a single letter code) and click the search button. With my cable connection, it takes about 5 seconds to load 500 records. (The results page is purposely limited to 500 records with no paging allowed. That was done at the request of my customer but I won't get into all the details about why other than to say that it had to do with his business structure and was not a function of the WAS capabilities.)

[CALocklin]

By the way, that example page of mine takes about 1/2 the time to display 8 records as it does to show 500 records. The size of the page with 500 records is about 200K but with 8 records it's only about 8K which means the 8K / 8 record version should be an almost instantaneous download. I believe the reason for this non-proportional time difference is that each search runs a very complex query which means that Lightnining Optimization usually doesn't work. My guess is that the query itself takes about 4 seconds and the rest is download time.

This is also supported by the fact that the 500 record page will begin to print about the same time that an 8 record page starts (4 seconds on my system). Presumably the rest of the time is spent downloading the other 492 records worth of HTML - about 192K worth.

[bowenjohn]

Cal: Nice site...good response time also...

[Lenny Forziati]

Performance when using components does not scale linearly. So while there are different ways to get to 2100, 1x2100 and 21x100 are very different in terms of server load. Instead of testing a single page with many rows in a single request, test a single page with less rows but requested by multiple clients. There are a number of commercially available and open source tools for simulating web traffic or you could build one in Xbasic without too much work.

In terms of the actual problem you are trying to resolve, unexplained lockups and problems, I actually would have asked for a copy of your application and your server logs up until the time a problem ocurred, along with detailed instructions to recreate the pattern if it is reliably reproducible. If you'd like to send me those things, I will try to take a closer look at this tomorrow.

Lenny, the question and issue was not concerning a real world application or even a well designed application. It was nothing more than to reproduce a problem with WAS.

I was having unexplained lockups and problems with nothing near 2100 fields and if I would have posted that statement you would have ask me to see if the DEMO had the problem. So I created a very easy to create example of the problem.

As for the 2100 number you could also do a little different calculation and would come up with some very real numbers. For example if you had a form with 8 columns and only showed 20 line items you would hit your 2100 number in 13 users.

Considering 25, 50 or 100+ users or more columns and less line items and you statement below creates real problems.

It goes to the very integrity of a production application.