[FX.php List] Performance issues with FM's xml interface

[Dennis Crall]

I've identified the source of the performance problem. My layout had four
container fields, and once they were removed the requests return almost
instantaneously.

We are speculating that it is costly to build the url for the resource, but
I'm not sure that accounts for the entire problem. Additionally, FileMaker 7
is much slower than FM6 in serving up the image. I wonder if the XML engine
is making a test query (not necessarily returning all the data) to the image
to make sure it is valid?

Clearly, storing  the images outside the database is one solution. However,
having the images in the database is helpful for our client in this
situation, and I hope FileMaker will work on this issue.

Denny

I'll


On 9/28/05 6:58 AM, "Jason H Awbrey" <jawbrey at harmonic-data.com> wrote:

> Dennis,
> 
> I think Michael had some great points. We were having similar issues
> with a large FileMaker solution. I was getting 5-7 second query times
> for things that should have taken no longer than a second. To go
> beyond what Michael is suggesting, we moved all of the tables that
> were being accessed from the web via XML to a separate file. We did
> not access via relationship any fields in the main file. This seemed
> to give us the desired result. I'm sure there is some explanation as
> to the slowness -- one thought was multi predicate relationships or
> calcs that used data from the main file.  I'm pretty sure it was
> something along these lines but never got a definite answer from
> FileMaker.
> 
> HTH,
> Jason
> 
> ~-~-~-~~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> Jason Awbrey
> Web Integration
> FileMaker 7 Certified Developer
> Harmonic Data Associates, Inc
> http://www.harmonic-data.com
> jawbrey at harmonic-data.com
> ~-~-~-~~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> 
> 
> 
> On Sep 27, 2005, at 7:19 PM, Michael Layne wrote:
> 
>> Dennis,
>> 
>> First, as for FileMaker, I've worked on several projects where we
>> EXPECTED 7 to be faster than 6, and it in fact was not.  That is
>> another issue/debate, but when building solutions via XML (FX.php)
>> for the web, I always take the following steps:
>> 
>> - create a separate layout for anything that is called via XML.
>> - only place pertinent, necessary fields in the layout.  related
>> fields are fine, but use only what you need...  you want it
>> practically naked, it's so spartan.
>>     (* remember, if you have related fields that are not always a
>> 'valid' relationship, place them in portals)
>> - summary fields slow things down, as well as anything that slows
>> down FMP.  It's hard if you have a primarily FMP client based
>> solution, but I usually try to do all logic, calculations, etc
>> within PHP.  When it comes to the web, it helps to think of FMP as
>> a place to store data whenever you can.  I start that way, then add
>> the necessary FMP functionality.
>> 
>> HTH,
>> 
>> Michael
>> 
>> On Sep 27, 2005, at 5:36 PM, Dennis Crall wrote:
>> 
>> 
>>> Hello,
>>> 
>>> [I posted this note to the FileMaker Experts list last week, but
>>> since the
>>> question involves FileMaker's XML interface, I thought someone on
>>> this list
>>> may have encountered similar problems.]
>>> 
>>> We're in the process of upgrading solutions from FileMaker Server
>>> 5.5 to our
>>> FileMaker 7 Server Advanced configuration. We've tried to follow best
>>> practices, and for the most part the solutions are working well.
>>> We have
>>> combined solutions with multiple files into a single file, and we
>>> run all
>>> databases through Metadata Magic to fix any corruption.
>>> 
>>> Unfortunately, we have noticed some performance issues when using
>>> the XML
>>> interface (e.g. FX.php). In some cases, the performance hit is only
>>> moderate. Pages that used to load instantaneously now pause before
>>> they
>>> return. However, in one solution (an FX.php site), we have pages
>>> that used
>>> to have small waits (1-5 seconds) that now take over a minute.
>>> Obviously we
>>> expect solutions to be faster under the new configuration. Our
>>> hardware is
>>> fairly beefy.
>>> 
>>> In all cases, the databases are responsive through the FileMaker
>>> client
>>> interface. And the performance issues are evident by making a
>>> straight http
>>> request to the xml interface. The solution with the greatest
>>> performance
>>> issue does use a large layout and has a couple of container
>>> fields. The
>>> container fields hold images (jpegs and gifs) that are under 100k
>>> -- not
>>> that the image size should effect the xml performance.
>>> 
>>> So I guess I'm looking for places to start. The problem does seem
>>> to be
>>> general to the configuration, and possibly isolated to the xml
>>> interface.
>>> Any advice on how to proceed is appreciated.
>>> 
>>> Thank you for your time,
>>> 
>>> Dennis Crall
>>> ITS-Academic Technologies
>>> The University of Iowa
>>> http://at.its.uiowa.edu
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>> 
>>> 
>> 
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
> 
> 
> 
> 
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list