4 Replies Latest reply on Jan 13, 2010 11:48 AM by ProZachJ

    Filemaker Online Incredibly Slow

    MorgaanSinclair

      Title

      Filemaker Online Incredibly Slow

      Your post

      Dear Folks ...

       

      Our company just moved our databases online with Filemaker, and now reports than used to take 45 seconds on our old, and not terribly fast, desktop now take more than 14 minutes. I think something is wrong with the scripts, as I can't imagine that the server is that slow. Is anybody else having this problem? It seems to revolve around the sorting, which takes forever.

       

      Is this slow-down typical of Filemaker online, or is it a script problem?

       

      Cheers,

      M

        • 1. Re: Filemaker Online Incredibly Slow
          littledog
            

          You access FM via IWP, PHP or fmnet? Do you use Server or not?

          The main typical question is about network - speed, traffic, computer LAN speed, firewalls etc.

          Normally you cannot feel the difference - FM is on local computer or you access via network using FM sharing (fmnet) or PHP, IWP is a bit slower.

          Check your computers for FM minimum hardware requirements. FM database computer must be at least MacMini and do not run many other programs on it.

          Also take look on network switches (cheap ones can be slow regardless what thy say).

          This is not FM question but is networking and hardware question.

          • 2. Re: Filemaker Online Incredibly Slow
            MartinBrändle
              

            It may be as Peter said, combination of slow hardware and network. Most probably.

             

            But the problem could also be caused by a wrongly designed database, e.g. if it uses self-joins that have as effect that the complete record set must be transfered to the client to resolve the self-join. We had such a case when we converted a large solution from FM6 to FM7. For the small databases, everything worked like expected, but for the big dbs we experienced a large slowdown which made that databases nearly unusable. Network monitoring then showed that every time a new record was created, 50 MB of data were sent from FileMaker Server to the FM Pro client. Even with a 100 MBit/s network this takes time. (When the databases were not hosted, but operated locally, everything worked fined.) After removing those self-joins that were used in FM6 as a workaround and reprogramming these parts, everything worked as fast as before.

             

            Please be more specific about your setup (hardware, FileMaker versions used). 

             

            • 3. Re: Filemaker Online Incredibly Slow
              penelope
                 I have exactly the same problem. I'am using ruby on rails. Did you resolved this?
              • 4. Re: Filemaker Online Incredibly Slow
                ProZachJ
                  

                I had a similar problem when we tried to access our production database via Remote FMP client. Turns out my scripting/ design was very inefficient. I was using alot of calculations (unstored) and summarys (sorts) that where having to look several tables "down" from the table my layout was based on.

                 

                --------------------------------ignore my technical mumbo jumbo and skip to the end for a solution to the problem---------------------------------- 

                 

                For example to caclulate the cost of an order:

                Orders table ---> Order Level options (several options on one order that had to be multiplied by quantity and then added.)

                                 ---> Order Units --->prints ---> finishing options (each unit could have several prints that could each have different finishing options

                                                                             @ differnt costs

                 

                Since each order could have options and finishing changed everything had to be unstored. Plus I was getting my base prices by deconstructing(through calculations a total unit price that was passed to me by my order reciept program) Alot of things where accomplished by summarys (sorts) that could have been done much more efficiently through calculation. When an order had 1000 units loading everthing over the local network was fine but remotely took WAY too long. Even worse was calculating a customers total revenue to be displayed on their customer record for my agents to see.

                 

                -------------------------------------------------------------------------------------------------------------------------------------------------------

                 

                 

                 

                The solution was to make new layouts for use by remote clients, minimizing summarizing (sorts) and calculations that looked more than one table "down". Also for the customers total revenue I just created a Field in the customer table that is added to by script each time an order is completed. Alot of times when you start with FM summary fields seem like a good solution because they are simple to implement, but often the are not the best way to accomplish what you need.

                 

                So I will attest that if your design is wrong, bad summarys, calculations, and scripting can equal very slow performace even with great hardware.

                My redesigned interface has all the funcitonality of the old one, but is just as faster over the NET as it is locally.