BTW - whilst these figures have been carefully researched and tested fairly widely I would welcome any comments showing contrary evidence - research will always be improved on as more people look closely at a topic.
Thank you so much for spending the time on this!
Thanks camp software,
I appreciate your appreciation.
This is a small takeaway from a large research project I have been undertaking so there will be more in due course.
Hi Nick...I just wanted to thank you as well. Much appreciated.
Thanks Jasongodoy, my pleasure.
Here is an interesting FMS performance point that has just surfaced.
I have noticed that Windows doesn't seem to run as fast with FMS14 as does OS X.
Whether or not your server is using a web sockets transport layer makes a big difference to performance and with Windows you need IIS 8 and a real (not self signed) security certificate to use web sockets.
I would interested to know whether anyone can add to this as it sounds pretty important, i.e. without a secure certificate you lose performance.
we have a Windows2012 R2 Server with FMS14 and a 100 % single database Webdirect solution.
The server has a QuadCore 2.20 CPU and 16 GB Memory.
The overall size of the database file is 400 MB.
We allocated 6000 MB to the FMS14 database server, which leaves 10.000 MB for Webdirect sessions.
We notice a enormous loss of performance in FMS 14 compared to our also still working FMS12 / IWP solution.
That runs with exact the same logics much faster on a much smaller Windows2008R2, SingleCore 8 MB platform.
A screen recording (unfortunately it is forbidden to attach that) shows both the WebDirect version and the IWP version in one combined screen.
The first time you switch to the details screen for one portal record it can take up to 5 seconds.
In IWP in the lower screen this is never more than 1 second.
Only subsequent visits to the same record details show similar performance in Webdirect as in IWP.
I guess this is because only then the record details are stored in cache memory.
Do you, as a 'senior' performance analist, have any idea what might cause this low performance in WebDirect?
Both installations run exactly the same script logics.
And a second question if I may:
Do we oversize the cache allocation by assigning 6000 MB to a single file solutions with a 400 MB in total single database file?
Hi User 16545
There is a fundamental difference between the service offered by FileMaker Instant Web publishing and FileMaker WebDirect.
IWP automatically created a very thin version of the FileMaker client interface and delivered that as a web service.
WebDirect now does a very good job of producing virtually the whole of the FileMaker client experience in a web browser.
There is in consequence a very big difference between the amount of data required to be transmitted to produce the user experience between instant Web publishing and WebDirect, and you will appreciate that WebDirect has to transmit much more than did Instant Web publishing.
You could check this using a utility such as Wireshark (https://www.wireshark.org/download.html) to find measure the amount of network traffic on each type of connection.
You can tackle the issue of the amount of data being transmitted by seeking to simplify your solution.
The first step is to ensure that all the layouts in your solution properly use styles forming part of a theme and that no layouts utilise local styles. This is because local styles (essentially a big lump of fmcss) are downloaded for every layout that is displayed and this ux data will very likely greatly exceed any of your own data you you want to view. When you use a theme correctly the amount of data required to properly display screen is much much less.
I suggest that you take a look at the various published pieces I produced over the past few months which can all be found here for a significant amount of detail on how to get the best out of FileMaker performance wise.
In particular regarding deployment take a look at the first two parts of my report on FileMaker Server Performance and take a look at the third part for some key guidance consolation development.
The report provides guidance on setting cache on server, too much is as bad as too little, you should allow 35 megabytes of RAM per web direct user session.
I hope that you find this helpful. If you wish to contact me direct firstname.lastname@example.org will find me.
This was very helpful.