Access speed on new server much slower than old (1 Viewer)

Alc

Registered User.
Local time
Yesterday, 22:15
Joined
Mar 23, 2007
Messages
2,343
I've found various questions about Access speed over a remote connection but can't find one that quite covers this problem.
Apologies if I've missed it.

Until two weeks ago, we had a load of databases on a shared drive (P:\). They were set up with a shared back end and each user having their own front end.
The P drive is used throughout the company, for a lot of things.

With the whole Covid 19 thing, all users have been working remotely.
The connection speed was fairly slow, so I was able to get our IT support to build a new, dedicated server (Q:\) to host just our databases. I moved all Access front and back ends over and remapped where required, but now the connection speeds are slow to the point of being unusable at times if accessing the databases from outside the company.

I'm hoping someone whose gone through a similar move might have experienced something along these lines and have some words of wisdom about what might be causing the drop in speed?

Thus far:
* IT can't find any network speed difference between the two machines. Not sure how they measure this but they did.

* If using a PC from within the building, the speed is much faster than using the old server within the building, which suggests to me that the drop when accessing remotely may be VPN related but doesn't explain the big drop between the old and new servers
 

Gasman

Enthusiastic Amateur
Local time
Today, 03:15
Joined
Sep 21, 2011
Messages
7,202
Once is a company I was working at, we were at a satellite location, but we had our own server and desktops in the same area in the same building, yet the server was slow as hell.?

Turns out all the traffic was going to the main site and then coming back to the satellite site, instead of going 2 or 3 feet to the server? :D

Not saying this is the case, but that surprised the hell out of me. :)
Might be worth IT checking the network structure/links anyway.

Try your own ping test to the servers anyway?
 

Isaac

Lifelong Learner
Local time
Yesterday, 19:15
Joined
Mar 14, 2017
Messages
2,859
I moved all Access front and back ends over and remapped where required
But the front ends are still on the users' machines, right?
 

Alc

Registered User.
Local time
Yesterday, 22:15
Joined
Mar 23, 2007
Messages
2,343
Once is a company I was working at, we were at a satellite location, but we had our own server and desktops in the same area in the same building, yet the server was slow as hell.?

Turns out all the traffic was going to the main site and then coming back to the satellite site, instead of going 2 or 3 feet to the server? :D

Not saying this is the case, but that surprised the hell out of me. :)
Might be worth IT checking the network structure/links anyway.

Try your own ping test to the servers anyway?
Thanks, I'll try it
 

Alc

Registered User.
Local time
Yesterday, 22:15
Joined
Mar 23, 2007
Messages
2,343
But the front ends are still on the users' machines, right?
Some are on the users' own PCs. Some are on the shared drive.
Normally all would be on one or the other but I'm experimenting to see if it makes a difference and the change is negligible.
 

jdraw

Super Moderator
Staff member
Local time
Yesterday, 22:15
Joined
Jan 23, 2006
Messages
13,407
I am not a network person, and don't know if (this LAN vs WAN ) does or could apply to your situation, but this comes up from time to time.
Front ends should be on user's PC --though they may copy a FE from a shared location to their machine at start up.
Good luck --please let us know how things develop.
 

Alc

Registered User.
Local time
Yesterday, 22:15
Joined
Mar 23, 2007
Messages
2,343
I am not a network person, and don't know if (this LAN vs WAN ) does or could apply to your situation, but this comes up from time to time.
Front ends should be on user's PC --though they may copy a FE from a shared location to their machine at start up.
Good luck --please let us know how things develop.
Thanks will do. I assume I can't be the only person this will happen to.
 

Isaac

Lifelong Learner
Local time
Yesterday, 19:15
Joined
Mar 14, 2017
Messages
2,859
Some are on the users' own PCs. Some are on the shared drive.
Normally all would be on one or the other but I'm experimenting to see if it makes a difference and the change is negligible.
Ok, thanks for the response.

I would think, if
- server A is where the backend used to be, people accessing it from home, using VPN
- server B is where the new backend is, people also accessing it from home, also over VPN

...and B is "much slower" than A, then surely the answer must lie somewhere in the server guys' setup, settings & administration....Sounds like the answer will depend on working with them to troubleshoot. Best of luck - that sounds frustrating, but hopefully now that they've invested in creating your dedicated server, they'll be motivated to figure out why it's actually worse than the last one.
 

Alc

Registered User.
Local time
Yesterday, 22:15
Joined
Mar 23, 2007
Messages
2,343
Ok, thanks for the response.

I would think, if
- server A is where the backend used to be, people accessing it from home, using VPN
- server B is where the new backend is, people also accessing it from home, also over VPN

...and B is "much slower" than A, then surely the answer must lie somewhere in the server guys' setup, settings & administration....Sounds like the answer will depend on working with them to troubleshoot. Best of luck - that sounds frustrating, but hopefully now that they've invested in creating your dedicated server, they'll be motivated to figure out why it's actually worse than the last one.
Sorry, I explained that poorly.
The two options are:
Front end back end both on new server
Front end local, back end on new server

Yes, I figure now someone has built it he has his name attached to it, so he'll want it to work even for selfish reasons.
 

Isaac

Lifelong Learner
Local time
Yesterday, 19:15
Joined
Mar 14, 2017
Messages
2,859
Oh. I thought that when things were on the P drive, they were not as slow as they are now.
Sorry I misunderstood.

Well ... Despite the principle of having FE's on local machine, which I espouse, I mean ... If they work better having each person's individual FE (that only they use) on the server, along with the back end ... I don't think there's much harm in doing so.

If anyone corrupts their FE, it'll just be a matter of a quick replacement with the shiny new master dev copy, just like if their FE was on local.
 

The_Doc_Man

Immoderate Moderator, Former MVP, Retired SysAdmin
Staff member
Local time
Yesterday, 21:15
Joined
Feb 28, 2001
Messages
18,390
OK, let's take a shot here at physical network configuration scenarios.

1. Access on local system, front-end on local system, back-end on shared server. This is the preferred configuration. Here is where with judicious use of indexing, you can make a system respond pretty well. All interactions between Access and the FE file are local. File locks within the FE are local. Lock collisions will not occur on local locks because you already have the objects locked. The only locks that are NOT local are those taken out for the back-end objects.

2. Access on remote system, front-end on remote system, back-end on remote system, using terminal services to have a remote desktop session. This should be very fast and will have relatively low network traffic. However, it depends on the ability to have a private copy of the front-end in a user's private profile. If FE files are actually shared, this configuration will be highly susceptible to DB corruption. Depending on the degree of sharing, will have lots of lock collisions.

3. Access on local system, FE on remote system, BE on remote system, NOT using terminal services because Access is local. Here, you run into the potential for a LOT of file locks. Further, since Access needs to pull all of the data across the network AND has to pull structural elements too, this will perform badly. If the FE on the remote system is shared, extremly probability of issues in corruption. Depending on the degree of sharing, will have very high occurrence of lock collisions.

Try to correlate between bad performance and one of those scenarios.

If the old and new servers are still available and visible to your users who are having the slowdown, you need to have them do a PING /n 4 from their computer to each server and take a screen-shot. If they do a PING /n 4 you must disregard the first ping as it is involved in route discovery. Once the route is discovered, all subsequent ping attempts should be more or less the same. That option says "Do 4 pings in a row and then stop." If you do that and there is a difference in the timing of the routes, you have something to take back to the IT guys.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 03:15
Joined
Feb 19, 2013
Messages
12,610
when working over VPN it is important to minimise the amount of network traffic. Terminal services is the most efficient as very little crosses the internet - just screen refreshes one way and keyboard and mouse movements the other.

If you haven't got terminal services to minimise network traffic, then you need to fall back on web page principles of minimum data - so forms should not be based on tables or queries without criteria. This applies to subforms as well and possibly to combos/listboxes if they return a large number of rows (e.g. a search combo listing 10,000 customers). Note also that the criteria function of openform is actually a filter - so all records are returned - it just displays the ones that are filtered.

Say you have 10000 customers, and you want to find one using a combo - that's 10000 records to be pulled through - perhaps twice depending on how your form works, once for the combo and once for the form. If you know before you populate the form and combo record/rowsource that the name of the customer starts with N then you only need to bring through those customers beginning with N so very simplistically with 26 letters in the alphabet only 400 records need to be brought through - a 96% performance improvement.
 

Alc

Registered User.
Local time
Yesterday, 22:15
Joined
Mar 23, 2007
Messages
2,343
Thanks all.
I've managed to get a dedicated resource from the technical team to look at this, this week.
I did some benchmark tests using various combinations of C, P and Q drive and was able to convince them that a problem exists.
Will post whatever we find.
 

The_Doc_Man

Immoderate Moderator, Former MVP, Retired SysAdmin
Staff member
Local time
Yesterday, 21:15
Joined
Feb 28, 2001
Messages
18,390
Good luck, there, Alc. The biggest part of getting this fixed is to convince the right people that something is broken.
 

Users who are viewing this thread

Top Bottom