Portal Performance issue with almost NO records

[MSPJ]

So I have a hosted solution, with a dashboard with a couple portals. When I go to scroll a portal, scrolling even one portal screen has a delay of a few seconds, ie I click the scroll bar or try to drag it, and it takes about 3 seconds before it moves. Running locally, it's instantaneous. Running on a dev server on my LAN, there's a slight delay, but minimal.

Having read various threads about this situation, my first thought was it's due to a filtered portal, so I removed filtering, but that made no difference.

I also read various posts about unstored calcs and other factors that would cause all the data to have to be transferred to the client over the WAN.

But here's the thing - at the moment, there are about 20 records in the database, related to the particular portal. 

Clearly, moving that data can't be the primary issue - right? 

I do have a lot of Execute SQL calculations in related tables, and I've read that can cause poor performance. But wouldn't that only be a factor when there are a lot of records?  

Are there design /schema choices that would cause significant lag regardless of the amount of data? 

Thanks,

Michael

[bcooney]

" Execute SQL calculations in related tables" - do you mean the the field's definition is an ESQL calc? I suggest not using ESQL in calcs because the performance hit can be huge if the table is open on the client.

Take all the fields but one out of the portal and test to isolate which is causing the slowdown. Ideally, non are unstored calc fields.

Perhaps post your file with test data?

[MSPJ]

Yes - eSQL in calcs - been using those a lot to avoid extra table occurrence groups and relationships.  Okay - will try what you suggested. 

Just for my understanding - can these cause this kind of delay even with so little data?  

[MSPJ]

By the way - can fields off the layout (over on the right) impact performance? 

Got it isolated to one field, unstored calc with eSQL statement, where it's taking the sum of a value in another table that is itself an unstored eSQL calc.   

[bcooney]

That'll do it. Why avoid table occurrences?

i found this classic very informative 

https://filemakerhacks.com/2014/08/08/shaking-the-dependency-tree/

[Fitch]

Agreed with Barbara. Emphatically do NOT use eSQL for calculated fields, or tooltips, or anything but scripted results. There may be a few exceptions, but that's the general rule.