MS Access on a shared drive – it’s only a good idea if your users like to wait

The first example is MS Access, and specifically, MS Access that is hosted on a shared drive. It takes very little latency (even 2.5 msec) to “break” the performance of an MS Access application deployed in such a way. The following example is one of many MS Access deployments that I had the privilege of testing, the results always look the same. The names of the transactions have been removed to protect the IP of the clients.

The baseline response time of a report generation transaction was 19 seconds. Once tested with 2.5 msec of latency, the response time jumped to 45 seconds, the following analysis reveals why:

Generate MS Access reports – 0 msec latency run

Without latency, this transaction spends about 10 seconds accessing the mdb file on the shared drive and the rest of the time is spent on executing the query to generate the report.

Generate MS Access reports – 2.5 msec latency run

Once network latency is introduced, this transaction spends 24 seconds accessing the mdb file on the shared drive and the rest of the time is spent on executing the query to generate the report.

So it is clear that there is a big performance penalty for file access, as by default file access is done using CIFS which is a protocol that is known to be very latency sensitive.

The following chart shows over 2300 CIFS File requests and over 1100 CIFS directory requests just for that single transaction.

So what can be done to improve the performance of this application?

There are several options when it comes to mdb MS Access files. In this example, the mdb file contained both the code and the tables. The first remediation attempt should be to export the tables to a SQL data base and link the SQL tables to the MS Access forms, this should reduce the size of the mdb file and thus reduce the performance penalty associated with accessing the MS Access mdb file remotely.

A more beneficial approach but at the same time, one that requires more changes, would be to export the tables to a SQL data base and replace the MS Access forms with web based forms. This architecture will eliminate the file server access completely as the client would be accessing data via a browser.

How was the analysis performed?

The above test used VE Network Appliance, VE Analyzer, VE ClearSight, VE Transaction Manager and Wireshark. The baseline and latency tests were conducted by isolating a client workstation behind the network emulator and injecting 0 and 2.5 msec of latency. During the test we used the packet list within the VE Modeler to capture the transaction traffic and we timed the response time using VE Transaction Manager.

At the end of the test we used VE Analyzer to perform deep packet analysis. Part of the analysis reports include the transaction markers report which enabled us to isolate the 2 transaction runs in WireShark (baseline and latency). The last step was to generate the above IO graphs in WireShark. These charts demonstrate the difference in the timeline and transaction footprint between the baseline run and the latency run. VE ClearSight was used to analyze the SMB protocol (CIFS) and to generate the last chart.