6 Replies Latest reply on Oct 2, 2009 7:44 PM by FluffyBear

    PHP API very slow



      PHP API very slow

      Your post

      my employer has recently started to look to Filemaker as a solution to all his problems. my specific task in all this is to create some PHP intergration of other lagacy systems, as well as a presentation platform for entities that need no access to bussiness logic and data.


      all is fine and i have not had too much trouble to learn how the API works. except that i have seen that it becomes extremely slow with even the smallest queries.


      for example, to just get the count of a findall query for about 5000 records takes more than 10 seconds(on the localhost!)

      inserting those records from a CSV file through PHP took longer than 10 minutes.

      performing the same tasks with MySQL/PHP will take less than a 20 seconds on the same machine.


      now maybe im not quite up to date on how to use filemaker effectively, but this is just absurd.




      // some initializing code here....

            function getrecordcount($table){      global $fm;      $result = $fm->newFindAllCommand($table)->execute();      if(!FileMaker::isError($result))           return $result->getFetchCount();      return 0;      }       echo getrecordcount('INVOICE').' records in INVOICE<br>'; echo getrecordcount('AGENT').' records in AGENT<br>'; echo getrecordcount('PRODUCT').' records in PRODUCT<br>'; echo getrecordcount('CONTAINER').' records in CONTAINER<br>'; echo getrecordcount('CONSIGNMENT').' records in CONSIGNMENT<br>'; echo getrecordcount('SALE').' records in SALE<br>';      


       oh, and as you can see i had to manually override php's memory limit to the script, otherwise it finishes with a FATAL error.


      please, any GURU, enlighten me about whats going on here....


        • 1. Re: PHP API very slow

          I also have this problem with wery slow loading of the Filemaker php api. I just installed FM Server pro advanced (10.0.2) on a new Xserve 2 x Xeon with Snow Leopard and even loading the php technology test page takes about one minute.

          Is it someone who know the solution on this problem?

          • 2. Re: PHP API very slow



            first: I don't use and know the FM PHP API, but I assume that similar thoughts apply as with XML/XSLT. AFAIK, the FM PHP API retrieves the data as XML, interprets it and stores it in arrays.



            The size of the XML stream returned - and hence the processing time - depends essentially on three parameters:


            - the number of records fetched

            - the number of fields on the layout 

            - the size of the data in the fields


            For what you intend to do (get the size of the result set), it is sufficient  to fetch 0 records. This can be controlled by using the setRange method, e.g. setRange(0,0) before you issue the find (in a XML query, this is similar to setting &-skip=0&-max=0). The XML stream that is returned still contains the number of records in the table. You may look up the XML/XSLT CWP guide that came with your documentation, chapter "Using the fmsresultset grammar". The table size is returned in the count attribute in element resultset <resultset count="xxxx" fetch-size="0">. 


            I use the -max=0 trick often for determining first how many records would be returned with a query, then turn sorting on or off depending on the result set size in another query. This speeds up the website considerably. 


            You may also create layouts that have the minimum number of required fields to improve answer time.


            But normally, without sorting and by setting -max to small numbers, one gets answer times below 2 seconds. You may try this query.



            • 3. Re: PHP API very slow



              you should not misuse another thread to post a question twice! See your original Slow php api on Snow leopard + FMS 10.0.2 Advanced .


              There was a recent discussion in the Technet mail list about using the PHP API with PHP 5.3.0 . The slowness might be attributed to the deprecated code the FM PHP API has when using PHP 5.3.0


              What happens if you install FMS with the recommended PHP version that comes with the installation CD?

              • 4. Re: PHP API very slow
                   Sorry for missusing this thread. I will continue this discussion in my Slow php api on Snow leopard + FMS 10.0.2 Advanced.
                • 5. Re: PHP API very slow



                  you should also use getFoundSetCount() instead of getFetchCount() 

                  • 6. Re: PHP API very slow

                    The default PHP API that come with filemaker uses the most verbose layout to retrieve data,  so there are many extra elements you do not need.  It does indeed make an XML call in a way that's not very efficient.  If you want to use filemaker and integrate it with php, you will have to write your own routines to interpret the XML data structure that is returned.  Chosing the XMLLayout that is less verbose of course...


                    I wrote such a class for our company,  the I/O time got reduce to about 20-25% from the original time.  Per call using FM PHP API reduced from 1.5 to around .3 - .5 seconds with the exact same layout and search criteria.


                    You can also further reduce the I/O time by creating data access layouts in FM.  If FM has to do any calculation or link across tables or DB then the response time from FM massively increases.  The differences can be as much as 2-4 records per seconds vs 500-1000 records per seconds returned.  Have only the fields that you need to access be on the layout and nothing else,  every additional fields on a layout increase generation and seek time on the server side.


                    Depend on the data usage needs, we have also built into our system memcaching mechanism to do session level caching so the web site doesn't have to do unnecessary I/O call.  A combination of writing our own XML interpretation routines and caching have worked very well.


                    It's not an SQL connection,  but it's fast enough where people don't notice too much.