XSLT is *%@#$%!@ slow !!!

[Frankywinky]

Months ago, we were on FileMaker Server Advanced 5.5 and we were using CDML on the web publishing engine and it was working fine.

Now, I'm happy to see that FileMaker makes improvements on the way of standards with the changes made on SQL, XML/XSL on WPE, etc.

But, I'm really disapointed by the performances of XSLT on my FileMaker Server Advanced 7 on my dual 2.7GHz PowerPC G5, 1.5GB SDRAM, with Mac OS X Tiger. So no problem with the server!

Performances were improved everywhere on FileMaker 7 databases, and with SQL, but not XSLT...

Okay, just to say how it is bad I've converted from CDML a simple webpage that directory our contacts and gives information on them (emails, tel number, address, etc.) It uses frames, on the top some searching tools, on the left, the result list of contacts (when loading at the first time, it is like a search without criteria, so all contacts with the "included in directory" enabled in our Database appears, there is something like 250 members of the directory on a total of something like 10000 contacts) and at right, the informations appears on the contact.

So, just to load the list of the 250 members of the directory, it takes something like 10 seconds (it was faster with CDML!) and when doing a lot of requests (by example, clicking on each contact of the list at left, one after one) after some time, it start giving errors and the user have to wait some time or to close the navigator and open it anew.

Note : In the Web Admin Console, I've enabled XSL in "production mode" (nor "development mode") and enabled the "Medium" level of cache (because of the small number of pages published).

Maybe the conversion from CDML is not optimal and I must rewrite everything to take advantages of the XSLT features? Or maybe I should enabled sessions in the console even if I don't need it? Or is there something else I must know? Any ideas?? :bang:

Edited July 22, 2005 by Guest

[Martin Brändle]

XSLT is slower than CDML when it comes to displaying a large number of records (say beginning from 200-300 records). It's the FM Publishing Engine that communicates with the DB and produces the XML tree, not the XSLT part.

Open a terminal and watch the processes "FM Publishing Engine" and "java" with the top command.

Therefore you should try to reduce the size of the XML tree by only providing those fields on the layout that are needed by the search and the displayed page.

In our projects, I started from converted CDML pages and optimized them, but also wrote a lot of XSLT pages from scratch.

[Frankywinky]

Thanks for your advice.

I'll try to look if I can optimize like you said.

I see that I'm not the only one to notice that XSLT is slower than CDML. I was hoping it was a bad configuration issue or something like that. Maybe, it is because WPE is using Java?

[Martin Brändle]

No. The most inner part which is slow, the FM Publishing Engine, is not written in Java. For me it looks like a downgraded FM Pro client that does the communication with the DB server and translates the layout, fields etc. to an XML tree. Unfortunately, it does not have the speed of FM Pro.

I reported to FMI that there are performance problems with this part, and also sent in some timings (obtained with the Mac OS X process activity monitor). Hope they will improve it.

The Java parts (XML parser, Xalan XSLT engine, and Tomcat) are fast.

Java was slow in it's v1.0-1.3 times, which led to the common prejudice that all Java programs are slow. It's not true anymore for Java 1.4 and higher.

[AnFrusch@pepp]

Hello,

I report my experience.

We was working with a large number of DBs, a large number of layout and fields and scripts.

The layouts were full of informations and the resulting XML trees was slowing down the performace of the web site (CDML wasa really faster!).

So I decided to create two new Db to store only the necessary table and fields.

The idea to create different layouts optimized for each query is the key to reach the best performances of the CWPE for me, I applied it and I now I can tell that I'm quite satisfy of the new platform, it's really fast now.

;-)

[Frankywinky]

You mean only creating some layouts with only all the fields you need in this layout or creating a new file with only the fields you need.

We already did the first solution but I think creating a second file synchronized with the first file must be impossible for us.

There is also a large number of calculation fields using a lot of other databases in other files, so maybe it does not help much...

Martin

Java is still slower than binaries. Even with a JIT compiler in the JVM, there is nothing to do, a VM is a VM... I think it is something like 20 times slower than an equivalent C/C++ program.

[AnFrusch@pepp]

You mean only creating some layouts with only all the fields you need in this layout or creating a new file with only the fields you need.

Hello,

yes I mean to create some layouts with only the fields you need.

synchronisation for me has been the best way to work, I've created two databases w/out any calculation, script, button, only simple data (text or number or date fields).

calculations is performed by the 'master database' which is made by almost 90 files (i reduced them to more or less 20 tables on the web).

Basically I use filemaker as a SQL back-end:

the layout solution works like a 'SELECT field,field FROM table' SQL statement.

I can tell that it works even better than 6 unlimited now, except for some unexpected errors that sometimes I find in the log file, but I cannot give an answer for them.