Computer settings in the server to speed up Alpha Runtime

[Tom Cone Jr]

Re: Computer settings in the server to speed up Alpha Runtime

Mike, I have found this article worth reading every 6 months or so. You might find it useful in your situation, as well.

[csda1]

Re: Computer settings in the server to speed up Alpha Runtime

Hi Mike,

I have been thinking all along that the problem was hardware, specially when I am still in XP for stations, but I could not forget the fact that every other app is working well. They coexist with a VPN connected outside the state and that is working well.
Internet from all station is working well.

I think you just gave the answer to your speed problems in the above, implied by the VPN reference. If you read my Record Locking 101 tips you would see that operating Alpha Five, or in fact any database (e.g. access, filemaker) that is not a true client-server (like SQL, Oracle etc) over a WAN (internet) will bring the operations to a crawl whenever a client system from a remote location (over the internet) is performing any reads or writes to the database. If you use Citrix or any remote program like PCAnywhere, TeamViewer, GoToMyPC, etc, you will not experience these slowdowns as it is just showing you a screen copy of a computer that is on the LAN (and not operating on a WAN).

And on my tips page, you will also find information about how critical good network hardware is and many speed tips.

My suggestion is eliminate all remote systems and see if your speed increases for a test. Also, try turning off your VPN for a test just to make sure that is not the issue.

[MikeData]

Re: Computer settings in the server to speed up Alpha Runtime

To Ira: Thanks for responding, but let me repeat.
Alpha program is not over the internet or via a vpn.
In other words The vpn and internet operations are not part of Alpha usage.
The server is local and the PCs are conected by a 24 ports switch box gig. The network is a server w2008 and Stations running XP.(by the way I did connect w7PC and the performance is the same).
Alpha resides in the server. The stations have a shadow Db created from the server as instructed.
To note 2 things: a) The problem manifest as more users login and slows the finding of records. 1or 2 user are perfect.
b) The other Db I did replace was in this enviroment as client-server too, it was fast. (I had to replace it for many other reasons)
based on those observations I have to conclude that is Alpha or just that I have set something wrong or not set.
I did find in one of your notes about indexing and I did add to the script to open of the form a sort on the Rec() and it does help a bit.

Tom, thanks for that link. I did glance at it. It looks good. I will have to redesign the system completely around that idea, if I had the time. I need to mention that the design I have is not by my choice. The client at each station has to look at the screen and see all the data as they are in the phone responding to the caller the large amount of detais in the screen. It would be very hard to click and click to see different sections .
Again they were used to function in the old system with such screen. Alpha is a more powerful product and yet I am having problems.

[Tom Cone Jr]

Re: Computer settings in the server to speed up Alpha Runtime

Mike you say that "Alpha resides in the server".

The typical desktop scenario would install Alpha Five (runtime) on each workstation, not the server.

The database files would be stored on the server, not Alpha. Network optimization of the database would create shadow copies of the database on the each workstation.

[MikeData]

Re: Computer settings in the server to speed up Alpha Runtime

I forgot to mention it. Yes the Runtime Alpha is in the Station, along with a shadow Db, in the server is only the main db.
I create a runtime version(only data) and send it to the server plus I increase the version #.
Then every user as they log in for the first time gets an "Updating Db Version# ".

[Tom Cone Jr]

Re: Computer settings in the server to speed up Alpha Runtime

Mike said:

The client at each station has to look at the screen and see all the data as they are in the phone responding to the caller the large amount of detais in the screen.

This is often said, but in my experience its rarely the case.

[MikeData]

Re: Computer settings in the server to speed up Alpha Runtime

I have been there for the past 10 years and believe me they do.
As a matter of fact in the new system I took some details and I put them in another table with a quick display and I had to convince them(well almost), that the data is just 1 click away.
I agree with you, but in this case they need it. Decisions has to be made by comparing many data fields.
It will be hard and confusing to click in and out.
Of course if they never had a program, any new concept could be changed. they had a system that did it.

[MikeData]

Re: Computer settings in the server to speed up Alpha Runtime

The problem as I see (correct me if I am wrong)it is in the increase of users. The response in a single is perfect for 2 users, is almost very good.
The problems becomes disrupting after 3 or 4 users. With 10 users, it is very impractical.

The table is big, but I notice a few things that I wonder if they could help improve the speed.
Example : Every time a user goes to a record, even with no change, it writes the date() and curuser() and the record is saved even after no one has changed anything.
If the user is opening the record in Querybyform why it works well the first time search, then it takes a while to clear the form or takes long to give the next record.

Any tricks or ideas are most welcome.

[csda1]

Re: Computer settings in the server to speed up Alpha Runtime

Hi Mike,

The problem as I see (correct me if I am wrong)it is in the increase of users. The response in a single is perfect for 2 users, is almost very good.
The problems becomes disrupting after 3 or 4 users. With 10 users, it is very impractical.

1 user is a special situation, where the data is not in a shared mode. 2 and up sharing data will slow things, but on a 1 gig network, a 100 users should easily be able to operate with good design, so 10 should have no problem even with a less than perfect design. Whatever your problem, it is not easily possible for 10 users to overwhelm the network (with totally functioning network wires, NIC cards, cables etc), unless they are all running queries or reports, or loading browses constantly at the same times. Even a call center of 100 people, typically has less than 1 save per second, easily doable on a LAN.

The table is big, but I notice a few things that I wonder if they could help improve the speed.
Example : Every time a user goes to a record, even with no change, it writes the date() and curuser() and the record is saved even after no one has changed anything.
If the user is opening the record in Querybyform why it works well the first time search, then it takes a while to clear the form or takes long to give the next record.

Any tricks or ideas are most welcome.

Sounds like you are doing queries, and not index finds. If you are doing queries (and a find-by-form is also a query), if you don't get LQO to happen, your queries have to access all records, a very inefficient thing to do.

As for lots of data on screen, sometimes a modal/modeless dialog box can contain a lot of the read-only data needed, without having to directly have the data connected in a set. There are many ways to display data that can be faster than a connection in a set's tables, depending upon it's common-ness and repeat usage.

[DaveM]

Re: Computer settings in the server to speed up Alpha Runtime

Have you looked at your sets? I have heard of sets being put together wih many tables and connections that were by several fields instead of one that severely slowed a system down.

I generally have connections that are index field(no s) and keep the table count per set to a minimum. A large one for me is 10 tables. I also try to avoid grandchildren. Not sure if it helps me, but satisfies my thoughts on that.

Any query needs to be destroyed after use

If there are things happening from the field rules that are changing records on a view, that can severely slow you down.+

as per Ira's good advice, It is not nec to make modal, you can open a form on top for viewing from any other table and hold focus until closed like this:

lockform.png

[MikeData]

Re: Computer settings in the server to speed up Alpha Runtime

The Form in Question is based on a table, not in a set.

Sounds like you are doing queries, and not index finds. If you are doing queries (and a find-by-form is also a query), if you don't get LQO to happen, your queries have to access all records, a very inefficient thing to do.

I would like to know more about this.
How do I get the LQO to happen in find-by-form request?

[DaveM]

Re: Computer settings in the server to speed up Alpha Runtime

http://wiki.alphasoftware.com/Lightn...ing%20Query%22 should be a real good start.

[MikeData]

Re: Computer settings in the server to speed up Alpha Runtime

Dave Thanks for the link, I see the indication is for creating queries. I have applied those in must of my queries.
But as Ira said even FINDbyForm is a query and I have no control in concatenating the search.
This the bottleneck
For most part in my case the user search in 2 character fields with numbers in it and/or Last name and first name fields.
I believe in search mode I could not create in the on event the concatenation.