NetTalk WebServer Performance Question

[rupertvz]

Hi Guys,

I am using a Clarion TPS database for a NetTalk WebServer.

The database and users are growing, and I need to plan at which point I will have to switch to SQL.
At the moment the performance is still fair.

We have 30 users with an average of 20 transactions per day / user (main table).

I realise that NetTalk does not make use of the key-range option for TPS as in Clarion desktop application, which might become performance issue for large TPS data sets in the long run?

Any comments will be appreciated,

[Vinnie]

Hi.

I am still using TPS files and works great very fast.

Trick is to have your data on a SSD drive.
Cheers

Vinnie

[Niels Larsen]

Hi

The key-range option isn't a Clarion feature but only a template way of helping you creating a filter.
If I were you, I would see Bruce's Clarion Live webinar (I think it's 413). I am sure you will be much wiser ;-)

I have used mssql for more than 10 years and the only thing I regret is that I did not start much earlier.

/Niels

[rupertvz]

Thank you Niels,

I have been using SQL for some of my new applications,

Unfortunately some older apps have been written with the TPS back-end and is not viable to switch to SQL.

[Bruce]

Hi Rupert,

>> I realize that NetTalk does not make use of the key-range option for TPS as in Clarion desktop application, which might become performance issue for large TPS data sets in the long run?

I don't want this answer to appear harsh, BUT...
Your understanding of what a "range" is is incomplete. There is fundamentally no such thing as a "range" - it is a pure template fiction carried over from the DOS days. Since Cw1.5 _desktop_ apps have used the VIEW as the primary data source, and this has no Range property.

Where the templates used the _concept_ of a range it is only to construct an appropriate View filter.

the Method API templates dispense with this fiction, and simply allow you to set the filter. If you set the filter correctly then it's exactly the same as having a template "range" option.

I _strongly_ urge you to watch the ClarionLive webinar's #413. I think I covered this topic here in some detail. (While you're at it you might want to review #409 as well - chances are there are other misconceptions you have carried forward from olden times...)

Cheers
Bruce

[rupertvz]

Thank you Bruce,

Just an observation with TPS table,

While updating records in a TPS table via a desktop application on the server (process procedure), then trying to view the records via NetTalk WebServer doesn't work.  The browser times-out.  I am able to view other tables via the WebServer just fine.

Will better hardware, such as SSD drive improve on this issue?

[Bruce]

Hi Rupert,

>> While updating records in a TPS table via a desktop application on the server (process procedure), then trying to view the records via NetTalk WebServer doesn't work.  The browser times-out.

So, as I understand it you are going onto a page (ie making a request of the server) then while constructing the answer to that request running a process procedure. The procedure takes longer than 30 seconds, so the browser times out. Is that right?

The solution to this is to use a progress control, with a start button. Nobody wants to wait 30 seconds (or more) for a page to load. so rather you make a form that opens fast, then starts the process (automatically or via a start button). Then they can see a progress bar as it progresses.

Cheers
Bruce

[rupertvz]

Thank you Bruce,

What I actually meant was,

While a user updates a record via NWF in a table (FILE001.TPS), there is a totally independent procedure running on the server side, doing updates in the exact same table.  (which is not related to what the user is doing in NWF)

While the process on the server runs, the NWF stalls completely and eventually times-out.  (as a result of the procedure running on the server side updating the same table)

Will better server hardware resolve this issue, or is SQL the only solution here?

[Bruce]

>> While the process on the server runs, the NWF stalls completely and eventually times-out.

sounds like your remote process is locking the table. That's not ideal.

>> Will better server hardware resolve this issue,

better hardware will only make the other process finish faster. But that doesn't seem like a long-term solution.

The better approach would be to have the other process not lock the table while it is working.

cheers
Bruce