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

[Michael Layne]

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
>