WAN performance question

[gregm1]

We are trying to improve the performance of our Filemaker WAN performance and have identified several ways we might do this. Namely,

• move the interface file to an FM server at the remote site

• faster hardware

• the design of the db itself

• upgrade the FM server software to v12 (currently v10)

• invest in a faster WAN

So that we can measure the effects of these changes, our developer has written a simple latency measurement script into our main DB. The results so far are interesting, but I don't understand the difference between the read and write performance.

The script writes some text into multiple fields, then reads it back, then cleans up.

The average time for our GB Ethernet LAN is around 35-40 second total, with the read time roughly three fifths of the write time. Over the WAN, the read time is a few seconds slower, but the read time is significantly longer, by a factor of 9-11 times.

To test that this isn't due to any network asymmetry, I installed the same db on the remote server and observed similar results.

I would expect read times to be a little faster than write times on a disk based system, but I would have expected the WAN speeds to have displayed the same ratio.

Can anyone throw any light on why this might be?

[IdealData]

I have endured similar but now have 50Gb fibre on WAN. This has improved performance dramatically and now the slow bit is the end user broadnand speed as we are delivering faster than the user in BOTH directions.

Understand that typocal broadband only SENDS around 10% of the quoted download speed, so thats the slow bit in your equation.

Quickest test is to get some service on hosted site that is not throttled back and conduct tests again.

Your script seems to take long time so maube you have calc fields on dispalay and these are updating with the data being written, this forces fm to read back the record and so on for each new data entry. Use a layout with no fields to avoid this.

HTH

[Vaughan]

Something to remember about standard internet connections is that they are not symmetrical: that is, the data speed is different depending on the direction.

Usually for domestic (home) internet, people spend most time reading web pages, which is downloading information, and very little data gets uploaded. So the connection is usually faster for download than upload. Significantly faster too: I'm on wireless broadband atm and the download speed is 3 Mbps while the upload speed is <1 Mbps.

[gregm1]

I should have said that the service at both ends is a symmetrical un-contended fibre service, 20MB at one end and 10MB at the other.

[Vaughan]

I should have said that the service at both ends is a symmetrical un-contended fibre service, 20MB at one end and 10MB at the other.

Yeah, probably should have mentioned that. LOL

Remember that the ethernet connection for the local area network is up to 1000MB which is 50 times faster.

Also consider latency which is the response time: different from bandwidth and apparently high latency can quickly make the database performance quite painful.

[IdealData]

Based on the apparent simplicity of the script the running time for the script seems excessive in Gb LAN, please post the script so we can gain more insight.

[gregm1]

The key question I'd like answered is this. What is causing the ratio between read and write times to be so markedly different when working over the WAN?

Here is the script:

Set Error Capture [ On ]

Set Variable [ $RecordTest; Value:500 ]

Perform Find [ Specified Find Requests: Find Records; Criteria: zz__LatencyTesting:

_TestAutoEnter: “=” ]

[ Restore ]

If [ Get ( FoundCount ) = 0 ]

Show All Records

Delete All Records

[ No dialog ]

New Record/Request

Set Field [ zz__LatencyTesting:

_TestAutoCalculate; "" ]

Set Field [ zz__LatencyTesting:

_TestAutoDate; "" ]

Set Field [ zz__LatencyTesting:

_TestAutoEnter; "" ]

End If

Set Field [ zz__LatencyTesting::g_ProcessRunning; "Write Processing 0%" ]

Set Field [ zz__LatencyTesting::g_StartTime; Get ( CurrentTime ) ]

Set Field [ zz__LatencyTesting::g_ReadStartTime; "" ]

Set Field [ zz__LatencyTesting::g_ReadEndTime; "" ]

Set Field [ zz__LatencyTesting::g_WriteStartTime; Get ( CurrentTime ) ]

Set Field [ zz__LatencyTesting::g_WriteEndTime; "" ]

Set Field [ zz__LatencyTesting::g_TidyUpStartTime; "" ]

Set Field [ zz__LatencyTesting::g_TidyUpEndTime; "" ]

Set Field [ zz__LatencyTesting::g_EndTime; "" ]

Commit Records/Requests

[ No dialog ]

Refresh Window

#Run Write Test

Set Variable [ $i; Value:0 ]

Loop

Set Variable [ $i; Value:$i+1 ]

Exit Loop If [ $i=$RecordTest ]

New Record/Request

Set Field [ zz__LatencyTesting::g_ProcessRunning; If ( $i < ($RecordTest / 4) ; "Write Processing 0%" ; If ( ($i > ($RecordTest / 4))

and ($i < ($RecordTest / 2)) ; "Write Processing 25%" ; If ( ($i > ($RecordTest / 2)) and ($i < ($RecordTest / 1.3333)) ; "Write

Processing 50%" ; If ( ($i > ($RecordTest / 1.3333)) and ($i < ($RecordTest / 1)) ; "Write Processing 75%"; "Write Processing

100%"))) ) ]

Commit Records/Requests

[ No dialog ]

Refresh Window

End Loop

Set Field [ zz__LatencyTesting::g_ProcessRunning; "Write Processing 100%" ]

Set Field [ zz__LatencyTesting::g_WriteEndTime; Get ( CurrentTime ) ]

Commit Records/Requests

[ No dialog ]

Refresh Window

#Run Read Test

Set Field [ zz__LatencyTesting::g_ReadStartTime; Get ( CurrentTime ) ]

Set Field [ zz__LatencyTesting::g_ProcessRunning; "Read Processing 0%" ]

Commit Records/Requests

[ No dialog ]

Refresh Window

Set Variable [ $i; Value:0 ]

Loop

Set Variable [ $i; Value:$i+1 ]

Exit Loop If [ $i=$RecordTest ]

Go to Record/Request/Page [ $i+1 ]

[ No dialog ]

Set Variable [ $Read; Value:zz__LatencyTesting:

_TestAutoEnter ]

Set Field [ zz__LatencyTesting::g_ProcessRunning; If ( $i < ($RecordTest / 4) ; "Read Processing 0%" ; If ( ($i > ($RecordTest / 4))

and ($i < ($RecordTest / 2)) ; "Read Processing 25%" ; If ( ($i > ($RecordTest / 2)) and ($i < ($RecordTest / 1.3333)) ; "Read

Processing 50%" ; If ( ($i > ($RecordTest / 1.3333)) and ($i < ($RecordTest / 1)) ; "Read Processing 75%"; "Read Processing

100%"))) ) ]

Commit Records/Requests

[ No dialog ]

Refresh Window

End Loop

Set Field [ zz__LatencyTesting::g_ProcessRunning; "Read Processing 100%" ]

Set Field [ zz__LatencyTesting::g_ReadEndTime; Get ( CurrentTime ) ]

Commit Records/Requests

[ No dialog ]

Refresh Window

#Run TidyUp

Set Field [ zz__LatencyTesting::g_TidyUpStartTime; Get ( CurrentTime ) ]

Set Field [ zz__LatencyTesting::g_ProcessRunning; "Tidying Up" ]

Commit Records/Requests

[ No dialog ]

Refresh Window

Perform Find [ Specified Find Requests: Find Records; Criteria: zz__LatencyTesting:

_TestAutoEnter: “*” ]

[ Restore ]

Delete All Records

[ No dialog ]

Set Field [ zz__LatencyTesting::g_ProcessRunning; "Complete" ]

Set Field [ zz__LatencyTesting::g_TidyUpEndTime; Get ( CurrentTime ) ]

Set Field [ zz__LatencyTesting::g_EndTime; Get ( CurrentTime ) ]

[IdealData]

Obviously you do have an active field on the layout, this being the %age field to display the progress.

1. Remove the %age field

2. Remove all the COMMIT RECORDS

3. Remove all the REFRESH WINDOW steps

The remote end of the WAN is only half the host end, this will also affect matters.

Use a stop watch to test the time.

[fabriceN]

Although, as IdealData said your script could really be optimized. Take a look at this. I requires FileMaker 12, but I think it's worth compared to an expensive connection.