13 Replies Latest reply on Mar 20, 2012 10:41 AM by Stephen Huston

    performance issue: OS X, FMP 11

    everyman

      Ever since upgrading to FileMaker 11, we've been seeing occasional performance issues on client stations. When it hits, the problem is generally resolved by deleting ~/Library/Preferences/com.filemaker.client.pro.plist, but it will resurface in a week or three. Heavier users are heaviest-hit, and complain most often.

       

      The database is served up by FMS11; it is fairly simple, 10 tables and 19TOs, all tables but one are almost entirely static.

       

      Client workstations have FMP 11, OS X 10.6.[4,6,8]. (One user is on 10.5.8.) All have had the problem. Nobody had the problem with FMP/FMS 10.

       

      Has anyone else encountered this, and if so: is there a better fix? This really shouldn't be happening.

        • 1. Re: performance issue: OS X, FMP 11
          Stephen Huston

          Please explain exactly what you mean by "occasional performance issues" -- that's a bit vague for troubleshooting.

          • 2. Re: performance issue: OS X, FMP 11
            everyman

            Yes, it is a bit vague.  I should have been more specific.  Spinning beach ball, for several minutes, when displaying a record.  Quit FMP, delete the plist, restart FMP, and all is well again.  This is not a huge database, maybe 5000 records in the main table and a couple hundred (or a couple dozen) in the other tables.

            • 3. Re: performance issue: OS X, FMP 11
              Malcolm

              Yes, it is a bit vague.  I should have been more specific.  Spinning beach ball, for several minutes, when displaying a record.  Quit FMP, delete the plist, restart FMP, and all is well again.  This is not a huge database, maybe 5000 records in the main table and a couple hundred (or a couple dozen) in the other tables.

               

              Getting all the OS software and FMP client and server at their most up-to-date levels often sorts out problems.

               

              malcolm

              • 4. Re: performance issue: OS X, FMP 11
                positivey

                We have a similar problem - most afternoons users that have been working the database heavily (FM11 client on server) find the local FM11 client bogs down and takes ages to do anything.  Has been an issue since we upgraded to 11 which was quite some time ago.

                 

                We have not resorted to deleting the plist file - Quit and restart FM on local machine seems to fix the problem for a while but it then returns quite quickly - every night we shut down the client machines so they start afresh each day. 

                 

                It is not a server problem as other users are happily accessing. Database is big with many tables, lots of relationships and lots of scripts but I don't think size is the issue as even simple searces or tasks become slow.  Even simple tasks like Go to Related Records is slow and does not involve a script so it's not executing scripts. It's not other apps interfering as we can have the problem with only FM11 running.

                 

                Users experiencing the problem create lots of new records and switch between layouts frequently to access information, mostly controlled by scripts.  It seems like the app is short of local memory and so struggles to do anything and that's why quitting fixes it.  I'm wondering if I am missing something like Commit Record commands so it is not closing off process cleanly in many places which then leaves the cache or similar clogged.  This is an old database that has evolved over many years.

                 

                This is on Mac and problem has been there for many updates of the OS.  Server and Clients are all up to current version.

                • 5. Re: performance issue: OS X, FMP 11
                  everyman

                  The OS X 10.5.8 client can't go any further (the site's last PowerMac, and will finally be retired in about a month).  Some, but not all, of the other clients are at the latest revision of OS X 10.6, as is the server.  I do not believe this is an OS issue, as it occurred almost as soon as FMP 11 was installed a few months ago (and never, ever occurred under FMP 10).

                   

                  FileMaker (client and server) are at the latest revision, and have been since installation.

                  • 6. Re: performance issue: OS X, FMP 11
                    everyman

                    I would be interested to know if your problems resolve after deleting the plist, and whether that "fix" lasts longer than your simple quit-and-restart.

                     

                    The user with the most frequent problems is the heaviest user; he switches layouts frequently, and opens multiple windows.  There are very few scripts, and most of them are for printing (almost none for navigation).  Most navigation is done by selecting from the layout menu.  (Ugh.)

                     

                    This is also a database that has evolved over many years (about 20) and really, really should be rethought and rewritten.  That process is ongoing.

                    • 7. Re: performance issue: OS X, FMP 11
                      positivey

                      I will try deleting plist but I assume you also restart FM client so it will be hard to see if that works better as every day we restart anew and we already get a varying length of time between the problem arising - can be daily to a few days or even a week before it happens again.

                       

                      We operate with a single window, switching layouts within that window.  The nav bar is available in many instances and so they can move from record to record without script intervention.

                       

                      Is your user creating (many?) records or just editing existing info?  Printing may also be related for us as my users also print what they enter (so much for a paperless world...).

                      • 8. Re: performance issue: OS X, FMP 11
                        everyman

                        At this point, they are mainly editing (or viewing) existing information --- perhaps two dozen records each day are created or modified.  The information is truly read-mostly, but even for that they get the spinning beach ball.

                         

                        Our experience has been that a quit/restart FMP cycle does not clear the problem: it almost immediately goes back to beach-balling.  After deleting the plist, it takes some time --- maybe a week or two --- for the problem to recur.

                        • 9. Re: performance issue: OS X, FMP 11
                          karendweaver

                          I have not seen this specific problem, but it does sound like these may be related to local memory problems.  Here is what I would do to troubleshoot, starting with the least expensive or time-consuming fixes and going to more complex or difficult steps:

                           

                          1. Check the RAM on each computer.  If these are older computers, they may be running on insufficient RAM for FM11, and that is a cheap and quick fix.  And in my experience, using the minimum requirements in the tech specs is a recipe for pain.  I use the recommended requirements as my minimum.  Even if your particular solution doesn't require it, the next version of the software almost always requires an upgrade from the minimum specs, and customers always complain.  Better to start out higher and get ahead of the game.

                          2.  Check the cache size in FileMaker preferences for each computer.  FM11 has a standard cache size of 64, but I have found that if it is users who are heavy users that are having the problem, I increase the cache to 128 or even max it out at 256 if they have enough RAM.  Searching and sorting are memory hogs, and if there are many or old graphics in the system, that can dramatically impact performance too.

                          3.  Also check the FileMaker preferences are not auto-saving during idle time.  Heavy users don't have a lot of idle time.  Set it for every 10 minutes. 

                          4.  If they are doing lots of searching and sorting - if any of that is scripted, you might try a flush to disk every once in a while

                          5.  Check for plug-ins.  Are they needed?  Are they up to date?  Remove them if unnecessary and update them if they are not current.

                          6.  If this is an old database - and it has ANY graphics for buttons, etc. - those could be a source of the problem.  Check them, if possible remove them and replace them with more modern gpahics or text buttons.

                          7. Check for network issues.  If only some users are having problems, could be a single bad wire or plug  or a router going south.  You won't necessarily see problems with other programs if this is the case - FM is very sensitive to network stability, so it's usually the first place problems with the network pop up.

                          8.  Do some database maintenance on a backup - save a compressed copy, save a clone and reimport data, do a recover and carefully look at the logs.  Then test a backup with one of your problem users.

                           

                          YMMV!!

                           

                          Karen

                          • 10. Re: performance issue: OS X, FMP 11
                            Malcolm

                            Check that the external data sources are correctly defined. Old solutions often carry lots of out-of-date references. If the application is running on FMS then all references should (typically) be "file:filename".

                             

                            Malcolm

                            • 11. Re: performance issue: OS X, FMP 11
                              Stephen Huston

                              What Malcolm said. Data references to other files may still work, but if the first option fails to resolve and it has to go to the second option in the list, that can take a full minute of beach-balling before it resolves.

                               

                              I've seen some old migrated system which started pre-7 which have multiple references to the same file, some of them relative and some of the as generic FMnet and some as fixed IP numbers. Each one that has to be tested can slow things by a full minute per test. Relative file-name-only references are the best to use if the files are all on one server. Remove/update ALL IP-specific references which are out-of-date.

                              • 12. Re: performance issue: OS X, FMP 11
                                positivey

                                Cache seems the likely culprit as was on the default 64mb and save on idle but users are rarely idle so I have set cache to 256mb and save cache to every 10 mins. 

                                 

                                I did have some obsolete references to external data sources so have cleaned that up - these are used during startup to locate a locally stored variables file for each user so really should not affect the database after it opens successfully - this is part of the old legacy before variables existed and is overdue for a rewrite. 

                                 

                                Thanks to all for the great pointers. Steve

                                 

                                PS Karen - what's YMMV!!

                                • 13. Re: performance issue: OS X, FMP 11
                                  Stephen Huston

                                  YMMV = Legal Disclaimer: Your Mileage May Vary