Loops in FM 13 very problematic

[Tompa79]

Hi

 

We (our company) have just noticed that loops in FM 13 is acting very strange. 

 

We setup a simple db-file on our 13 server (v5, windows server), to test a rising suspicion - (polling) loops work bad.

 

We compared loops and on timer script, with and without pause.

 

We let the script run for 15 minutes and did a count on how many iterations each setup managed to run during that time. The script is based on two clients - one that creates record, and the other reads and writes to the created record. The first client creates a new record when it sees that client number two has written to the last record.

 

1. 0,5 s delay, no loop, onTimer   451

2. no pause, no loop, onTimer   459

3. 0,5 s pause, no loop, onTimer  448

 

4. 0,5 s pause, no loop, reinvoke  28

5. no pause, loop     341

6. 0,5 s pause, loop     444

 

The first three is with onTimer. We tried 0.5 seconds of delay in the timer, no delay and also added a pause in the script with no delay on the timer. All three manages approximately the same number of iterations.

Number 4 is with a recursive call to itself - it crashed after 28 iterations.

Number 5..6 are done with loop. The difference between 5 and 6 is a 0.5 second pause. Notice that WITH a pause, we manage MORE iterations than without.

 

This might already be very well known to many of you, but the reason we did this test is that some of our customers experience very slow response very randomly on a part in our system that is based on a polling loop with a 0.5 second pause. We have wpe script calls that writes to the DB, but the polling/looping clients sometimes does not notice this write, right away as expected. It can take up to 10 seconds in several cases on LAN and over a minute over WAN.

We changed the loop to on timer script variant instead and that problem dissappeared. 

 

Since then we looked through our solution on other polling loops and noticed that we have random big delays on every one of them when we try to read a value thet already should be there. The random delays exist on every customer we have checked, that runs 13 clients. We are in the process of timing 12 clients also to see if the problem exist there too.

 

Unfortunately we did not get those random big delays on our simple test file.

 

Anyone else experienced this or have input that might shed light on this matter? 

[Wim Decorte]

I think you need to find a better mechanism than relying on FM's internal notification scheme for clients to get updates from the server.

 

Read this as a for instance: http://clickworks.be/en/trigger-script-another-client

[Fitch]

Are you using ExecuteSQL to "poll"?

[Tompa79]

Wim: Ok, We kind of hoped/assumed that by polling a specific relation, that FM would update that value more or less instantly - obviusly not. That's a very nice suggestion, thanks!  Unfortunately, even there, we have random delays. We now think that the size of our database and/or relationship graph in this GUI file, might cause FMS to have trouble updating out to client. I will have to try to have the hidden window open up a separate file containing only the needed table, to perhaps make the work of FMS a little easier.

 

What we also noticed on our hosted solution (WAN) is that clients on a really bad internet connection never get theese delays, only clients on very good connection have the delays (LAN included). - Super strange! The client on bad connection instead gets the more understandable delays on other parts of the solution.

 

Fitch: Not sql at the moment, but it makes no difference with the delays unfortunately (we tried).