PCs very slow accessing Database program

[HankstertheHun]

Our network is Novell.
We want to migrate to Windows 2000 Server because of our database system responds better to that system.
Until then, we are faced getting a faster response from 2 remote pcs. We have a fractional T1, (256k)
Does anyone have any suggestions for making the connection faster. (Takes 10 minutes to see first screen of the database program.)

Please offer suggestions.

Hank

 

[Comstocb]

A question needs to be answered first, is the 256k link saturated meaning the database apps are competing for time to send traffic through the pipe? I doubt this is the problem already as 10 minutes is most likely a client/server issue as the network session should have timed out. I am not an IPX expert so I can't be sure but a traffic capture will tell you volumes of whats going on. Give a little more detail and I might be able to help further.

Brian

 

[jimbopalmer]

one question, are you sending the executeables down the 256k or is this just the Database Data?

it may be worthwhile to load the executables locally to the PCs.

I tried to remain child-like, all I acheived was childish.

 

[HankstertheHun]

Thank you Comstocb and jimbopalmer.....
Because I am new to networking and Windows 2000 Server, a few terms I may not understand. Please bare with me. I'll do my best in providing better descriptions of any problems.

First: I believe the line is being shared with our local city network. Our Housing Authority has purchased 256k of the full T1 line. The 2 computers (Maintenance Dept) only use the database to enter work orders and inventory information. Is there a way that I can check to see if other activity is on the line?

Second: I do think it would be a good idea to have a copy of the executables on each of the local pcs. The database Tech Support stated that the data could not reside on the pcs - (old DOS based Flat File database). But I do agree that the executables should be OK if located on the 2 computers.

I am going to do more research.

Thank you both very much for the suggestions. This is a blessing for me. Thank you again.

Hank

 

[Comstocb]

This one is a can of worms: The problem is that the DB application is taking an incredibly long time to start (10 minutes). Your job is to find out why and there are MANY possible reasons. A little intuitive thinking can go along way here however. Do the two computers access any other remote applications or the internet to compare load times with? Try FTPing a file over the link to one of the computers,is it slow? If it is, the problem is network related, if not, the problem is with the client/server app and this needs to be investigated (also look at how the app interfaces/transmits data over the network). The bit of information provided makes me think that the sole purpose of thse two machines is to access this DB and this makes your job a little harder. Now you need to use "external" tools to gather information about the problem:

If you manage the switches/routers between the 2 PC's and the external DB, you can look at port statistics or use SNMP to determine the general health of the 256k link. This will only show you if the WAN link is the culprit however, if not, you have to look elsewhere for clues.

Your best bet is to use a laptop loaded with sniffer software such as Ethereal (free for download) and break the network between the PC's and the 256k link (easiest if done close to the PC) so you can capture the DB traffic in action. This is were an understanding of TCP/IP or IPX/SPX is required to determine what the behavior is. For example, I have found underperforming SQL servers by just watching the TCP/IP traffic at the remote PC having problems. When TCP sends a request that the server cant fulfill in a resonable amount of time (200ms I think), it will send the requesting PC an acknowledgement, that the packet was received and that signals the remote PC to be patient for the data. My customers PC would hang for 5 minutes at a time and it was all because the SQL server was taking its time to process the request. My seeing the acknowledgement packet told me immediately that the network delivered the packet and that the SQL server was to blame. In short, a sniffer can tell you volumes. I can't recommend them highly enough.

Honestly I have just scratched the surface here and my analysis is very general above and I left out detail that may change the results I spell out. I need to ask many more questions and get more data to really begin to help you find an answer but I hope this helps, let me know.

Brian

 

[HankstertheHun]

Thanks Comstocb. I am going to relay this message to my Technical Support man.

I contacted the company that supplies the database program. They were not to happy about having copies of the executables located on the two pcs hard drives. These executables are the files that are updated quite often.

As a wild,but very calculated move today, we made an attempt at Terminal Services for this situation. We manually input the IP addresses so the 2 servers (Windows 2000 Server and Novell Server) could talk to each other.

I setup the configuration for Terminal Services to automatically access the program (Desktop Icon).

I am going to use your mentioned suggestions (sniffer programs). Hopefully they can determine what is making the line so so slow.

I will be getting back in touch.

You are offering great suggestions. (Well, things I did not know about)

Thanking you again.

Hank