Meeting Notes 3/22/2006

From FMPwiki

Jump to: navigation, search

Meeting Notes

Barbara Levine 13:43, 27 March 2006 (EST)

1. Compare FMS/FMP to traditional client-server

Traditional architecture has all of the work on the server side. It requires a beefy server. FMP started with a distributed client model, based on the availability of under-utilized desktops. FMS 7 was the first to optimize server/client work distribution issues, by handling some processing at server.

2. Which tasks are performed at client and which at server?

Client does most of work for calculations, sorting, scripting. Server handles index management and finds. FMS7 – 8.0v1: FMS did all finds unless a local global was referenced, or a design function getting local info. One of the bugs, as found by Tony, if a calculation field referenced an external file on a second server, Server 1 could not talk to Server 2 to get it. All data in column would fill with question marks, and all records would be found.

8.0v2: fix many bugs, quickly: all unstored calculations now handled by client, which caused performance regression issues, as in FM 6. The fix: FMS will determine if it can do the find; if not, it will send to client.

8.0v3: pending updates for both client and server.


3. How do bit map ID’s work.

The server performs a find on a set of data. Instead of sending to client a list of record ID’s, it performs a bit map match. If 3 records were found, sends 0001001100, sends one bit per record, and compressed. This is the bit map image. Client receives the bit map, knows what it needs to display, and then asks FMS for the info that it needs to display. Bit map gets cached. If in list view, see certain amount of data, then a pause – this is when the end of the cache is reached. When memory is full, the bit map gets written to temporary space in the hard drive.

4. Why are WAN sorts slow? Sort on an indexed field are done by client. The delay is because the index has to be downloaded (in earlier versions of FMS, this happened when file was opened). Now it happens on demand. And, if further calculations are needed to display the data, it has to get the indices for the related data, and do the calculations. Indexing the calculated field may not make a difference.

If the sort field is not indexed, it has to bring down data on all records before sorting. But because of caching, if data was already brought down once, and has not been changed, the second sort will be much faster. A subsequent sort on a different field may still be able to take advantage of some of the cached data.

Cache file, as specified in preferences, is encrypted via a proprietary algorithm. If crash the computer and try to read the temp files, still cannot read.

5. Can you run FMS 8 and client simultaneously on the same machine?

Works OK. Takes care of locking OK. Use open remote as though a normal network client. Tasks run dramatically faster on the FMS machine then on the network. But it is not recommended to run FMS on the Terminal Server – it gags the server. OK to use the client copy on FMS for odd tasks.

Terminal Services to client on FMS machine can be safer for database design then a network connection. But make sure you understand how the TS is configured.

6. How is replace handled? At client, without record locking. Replace is ugly, it has to communicate to all the clients of the changes. Replace over server gets ugly. Replace on 2 fields via scripted set field is faster. Is it faster in form view, even with freeze window?

7. How is stored server data handled on client? It’s an intricate dance, and only the engineers really know. When a client starts to change a record, FMS is notified, and gives client OK to edit. When record is committed, client notifies FMS, passes data, and FMS needs to notify all other clients that record has been changed. FMS initially pushes out a flag that record has been changed. Not clear to Tony if the entire index is updated, or just specific records. Related records do get updated. In a high latency network, or a network near saturation, FMP does not get the update immediately. Record locking never fails, but updates may take time.

8. What happens during a momentary loss of connection with FMS? Disclaimer: the most intimate knowledge goes to FMS 5 days, watching with a packet sniffer during dropped connections. FMP would send query, FMS are you there? If FMS didn’t respond after 3 tries, it would drop the connection. Tony thinks it’s still the same now. Only FMS control is disconnect idle, and cannot configure.

Idle disconnect does not always terminate the users when it should. Usually FMS should disconnect a dropped connection within a few minutes.

For improving LAN performance, which is more important, latency or bandwidth? Both. Latency problems not as serious as before 7, but still significant. Most of small packets are bundled now, not nearly as chatty as in 6. Now we have larger view packets. Latency hurts less. Tony has a high latency high bandwidth connection (satellite): prior to 7, unusable. With 7, can open a database OK. Latency makes for slow layout changes. A large container contents on record displays quickly. On dialup, layout changes are quick, but large container display is slow.

Data is oriented towards bandwidth, and navigation to latency.

Cache helps. Once data is downloaded, you have it. A reused object on a layout is supposed to be cached, but that may not work for pasted objects.

9. What happens to a single repeated field displayed multiple times in a portal? If the object is stored in the file, it should not have to bring down the object repeatedly. But the cache might chuck container field contents when you navigate away. So a highlight might do better in the local file. Use a tiny graphic and stretch it in the layout. Less data to download.

In IWP: everything is a new page to the browser.

10. What happens when there is hidden data on the layout? If you have a tab control, everything is downloaded the first time, so tab to tab movement is much faster then separate layouts. Not true for IWP, where it’s a new page.

[Discussion about IWP vs. a thin client.]

11. Managing embedded documents in a WAN environment. What is best architecture? The specific documents are PDF’s. Each container field could be 2 GB. Embedded documents present backup challenges. If the containers change less often then the metadata, put them in a separate file, which gets backed up less often. Embed vs. reference: If you reference the graphics, you have to figure out the link, and all users need access to the shared location. With an autoenter calc in 7 & 8, you can make the link cross-platform; but if the paths is up in a Web Browser, set the reference there. Off load from FMS completely. Plus store some global info re: the path info, so it can be updated.

Locally available URL’s may be a good solution, preferable over file system.

Text in a container field can be exported.

Oliver exports a dummy container to delete a file.

12. Best practices for optimizing FMP over WAN & LAN. FMP is unique in database world in that data and logic and interface are mixed in a single file. Tony thinks we should embrace the unity. SQL Server is fast because it does not have to deal with calculations. Unstored calculations are really easy, and save time in building the database; but in a larger environment, we need to make an upfront investment in programming the database, to prevent keeping the users waiting. Avoid unstored calculations. Control the interface to calculate and store the invoice total when editing is completed, instead of using that easy unstored sum. Summary fields are as bad, or worse, than unstored calculations. Keep users out of unstored calculation fields in find mode.

13. What is the breakpoint for performance or reliability? Reliability issues over 100 connects. Performance issues not linear. Don’t overbuild the relationship graph. Multi-predicate joins: first predicate, FMP does result, sends bitmap. Does each predicate independently, sends bitmap, then next bitmap, sends bitmap. In 8, the date ranges are optimized for searches, gets concatenated into a date find. Tony tested building big keys (old way) vs. multi-predicate (two equals and a range). Up to 300k records, in a recursive custom function, results were same. Over 300k records, old way was faster. This was local, not network.

Autocomplete requires the index. Can be slow over WAN.

14. FM 8 Recover: FileMaker says it is good, and should be trusted to do what it is supposed to do: extract the data from a crashed database. It will toss any layouts or scripts with corruption. The data can be trusted to be sound. If FMS 8 crashes, reports that files are bad, & you recover, you can trust the data but not the metadata.

Tim had a 5 system with hidden corruption that never showed until the 8 conversion. Layouts would not print in 8. Recommendation from FMI Tech support: recover in 5, then reconvert. But had already spent 40 hours in 8. So recovered in 8, as per Tech Support. Layouts now print.

Oliver: told to export everything to text, re-import. In the past it helped remove the high ASCII characters. But now with Unicode, does it make a difference?

Save as compacted writes a new file, like in the 6->7 conversion. If it hits corruption that it cannot decipher, it fails. If it hits manageable corruption, it will rewrite.

V2 Recover has a documented bug on variable names.

15. Client vs. IWP: Tony does not think the WAN environment variable throws a lot in. FMP client vs. IWP: IWP is so limited, no subsummary reporting, printing, container fields. IWP has its place, in extending a database, to make it accessible over the Web, without learning XML or PHP. FMI has made it easier to identify the limitations. IWP is still a bad solution if we don’t know who the clients are. Netscape and IE 5 won’t work, just as though the client did not have FMP. Plus the 100 user limit. Custom Web Publishing offers a lot more, esp. PHP. Or look at Citrix for a more robust client. Or .net via Wim Decorte’s new tool, fmDotNet.

FMP’s strength is as a front-end database, not as a back-end database. ODBC performance has improved over the years, as has integration. Making more use of XML, like FX PHP, may be the way to go. XML is the fastest way to get data out of FMP, compared to ODBC, but it’s verbose.

John found a dramatic performance improvement in upgrading a client to gigabit switches.

Peter: Oracle uses much heavier hardware to support 100 users than FMP does.

Citrix vs. Terminal Services: many more management utilities, load-balancing, farm setup. ICA protocol is more efficient than RDC. ICA works over 16 k connection. Can grow it to a higher level. Better capabilities for more users. Multi-time zones. Printing much better.

FMP license: per CPU or per user.

Peter and Mary will work with number of FMP licenses required for Citrix users. FMI generally will not charge schools beyond the number of CPU’s. K-12 site licenses are inexpensive, and include at-home use.

Personal tools