WPE Performance

[sleeping]

I'm currently testing FileMaker Server 7 Advanced with different types of configuration in order to find which one offers the best performance for web publishing. So far, I have gotten horrible performance from all the setups, where a single simple request from the web has required no less than 6 seconds to perform (with network lag being insignificant in this case).

The times listed below are a rounded average of 100 consecutive (non-concurrent) queries on a database that has 35,000 entries, on a layout that has 3 text fields.

The machines I have tested it on are :

PC : Pentium4 3GHz, 512Mb RAM

Mac : dual-CPU PowerMac G5, 768Mb RAM

(1) WPE & Server7 on OSX 10.3.8 on the same Mac : 11 seconds

(2) WPE & Server7 on OSX Server 10.3.8 on the same Mac : 6 seconds

(3) WPE on OSX 10.3.8 on a Mac & Server7 on OSX Server 10.3.8 on another Mac : 11 seconds

(4) WPE on OSX Server 10.3.8 on a Mac & Server7 on OSX Server 10.3.8 on another Mac : 6 seconds

(5) WPE & Server7 on Windows 2003 Standard on the same PC : 6 seconds

(6) WPE on Windows 2003 Standard on a PC & Server7 on OSX Server 10.3.8 on a Mac : 6 seconds

(7) WPE on OSX Server 10.3.8 on a Mac and Server7 on Windows 2003 Standard on a PC : 6 seconds.

With (1) and (2) we could see that there was a great performance increase in using the Server version of the operating system rather than the client one, and with (1) and (3) we saw that it was really the WPE that was taking the most time to execute. However, no matter what was the setup, 1 machine or 2 machines, it always took no less than 6 seconds to perform a XSL request. The same kind of request made over the network from a FileMaker Pro 7 client returns a result in less than a second.

Looking carefully at the system monitor on the servers, we noticed that neither the CPU, nor the RAM, nor the hard drive was in huge activity during those 6 seconds, which leads us to think that most of those 6 seconds are spent establishing the connection between the browser and the WPE (or between the WPE and FileMaker Server?).

Has anyone ever experienced such long times for web publishing queries? Did you accept it or did you find a way to make it faster? How fast are your WPE connections? Is there a way to establish a persistent connection between a web server and the WPE?

Thanks a lot.

[Martin Brändle]

We don't experience slow performance. I do things like metasearch queries (e.g. a query is sent to several databases at once and the results are collected, at least 4 queries are involved in such a step) on databases with several 10'000 to 100'000s of records with more fields on the web layout than you have, and the answer times are usually below 2 seconds.

The server setup is 2 dual-CPU Xserves with OS X 10.3.8 Server, one is the DB server, the other the WPE/Web server. Both have two network cards. One card is for outside connection, the other for internal connection of the servers by a short cross patch cable.

But I don't think it's the hardware that has to be considered, it's rather a combination of FMS7A setup, database, XSLT and web design principles that may help to improve performance (real or anticipated):

- give as much cache to FMS7A as you can and FMS7A allows you to do.

- check the design of your databases. Self-join relations that involve calculation fields and auto-enter lookups are deadly for performance. Relationships with comparative operators are bad; it's better to define the "portal view" on the web side by adjusting the web query. Converted databases with filereferences that point to nowhere are very bad.

- place only the fields that you need on your web layout

- according to my observations, performance of the XSLT transformation engine is not a problem, it works quickly as soon as it has the XML data. Performance of the WPE that has to produce the XML resultset tree however is; it depends heavily on the size of the resultset. You see that I make a difference between the two, e.g. between the process "FM Web Publishing" and the "java" process

- therefore try to avoid large result sets, e.g. use a meaningful value of -max to limit them

- sorting of large result sets can be also bottleneck.

- and then the browser: Avoid nested tables in the HTML design; if you don't use techniques like colgroup, the browser has to wait until the last /table element before it can display the result.

- try to design the web page so that the user has the feeling that something happens, although not all results all already there. You can see that also here on the fmforum website when you click on "Forums": the website comes back fast, but not all the content is shown immediately.

[sleeping]

I'll check with the DB manager about the self-join and calculation fields and auto-enter lookups things. Maybe he can simplify the database for web use.

As for the webpage and all, it's really not the problem, the times I've measured are really the db request time, not the page loading/rendering time.

Thanks for the reply.

[sleeping]

It was indeed those infamous calculation fields... it appeared we had 10 of those in the table *shrug*

Thanks for the pointer.