The new MacPro is finally out, with over 400 or so configs.

 

Any recommendations on how FMS interacts with the possible HW configs? 

 

Specifically, the tradeoff between MHz processor speed and number of cores available?

 

How well does FMS use multiple core & threads?

 

The usual issues, eg RAM & HD, are not in question, since I will have enough RAM and a large SSD in any case.

 

 

Go for more cores instead of MHz speed.

 

Not sure if anything changed in FMS13 but:

FMS is fully multi-threaded but it does not split one thread across different processors.  So more processors means more threads being processed at the same time = faster response time.

Interesting take, I was trending towards Processor speed...

 

 

THanks!

There's so a lot more to selecting the most cost effective configuration for your purpose than simple clock speed versus number number of cores. See Marco Arment's great explanation here: http://www.marco.org/2013/11/26/new-mac-pro-cpus

OK, so it boils down to when FMPS can multithread something - only different requests, or can it multithread an "expensive" task such as un-stored calcs in large sets, sorts, or large scale records import/updates etc.?

That comparison is largely written from a desktop-use point of view, not from a server-use point of view.  Depending on the load you will get more benefit from more cores and not from the speed difference.

 

There is no available information on what one "FM task" like a calculation means in terms of number of threads.  We do know that one thread is not broken down and assigned to multiple processors.  One "tasks" can be multiple threads I'm sure so one "task" can be processed in parallel.

Wim,

 

in my case, I typically have <10 concurrent users, but some very large datasets, so the limiting factors are certain tasks that take long to complete, which is why I'm interested in learning more about what type of tasks are amenable to threading.

 

I understand this is not a trivial question, particularly given the way FM splits some work between server and client, and how even that split can change over time (now apparently giving back more to the server etc.), but any insight in how this is handled would help in my decision making.

 learning more about what type of tasks are amenable to threading.

 

I don't think we have any power of that.  Spawning threads happens at very low level inside the FM code.  We do have some way to what happens through the FMS statistics.  There is no information on threads but there FMS does report on the number of "calls" per second and the i/o and processor consumption per call.  While there is no information on the direct translation between one script step or one function execution and the number of calls it generates, it does give an overall impression of the load that we generate on the server.

 

That load is a combination of:

- the sheer number of users

- the users activity (creating data / aggregating data (summaries) / viewing data)

- our design (efficient vs inefficient)

- the hardware involved through the whole deployment (low disk space on the client for instance will generate much more client/server polling of data than if there is sufficient disk space, to give just one example of something that is often overlooked).

 

Slow performance can be overcome by throwing more horsepower at the solution, but the design of the solution should certainly not be overlooked.

So if you are the only user, you can see how many "calls" are generated by a function, I guess.

 

Can you assume that any additional "call" would go to the next thread or core? If so, you could do some estimates on the need for more cores vs faster cores...

 

Are there no FM engineers on this board with some insights on the low level thread spawning behaviors?

 

 

Also, am I correct to assume that the various GPU options have little to no effect on FMS performance?

 

Thanks!

I think there are too many variables to try and make a direct correlation between a function call or a script step and the # of calls.  It will also depend on what your client has in its cache and what the server has in its cache and depending on that, the same action could potentially generate more threads or less threads.

 

And there is zero information on what is call so I would not want to make any assumptions there.

 

GPU: doesn't matter.  The server does not draw a UI often.

FMI has published a Server Configuration Guide for past versions. I expect we will see one for Server 13 at some time.

As for part of the original question, do be sure to have adequate RAM, probably at least 12 GB. And a "large SSD" may not necessarily be the best choice for a server.

Steven

Hi Steven,

 

looking forward to the FMI server config guide, particularly if they mention the MacPro ;-)

 

and if it becomes available soon it will even be useful for my purchase...

They are not going to mention specific models like the Mac Pro. That would make the document instantly dated.

Have they discussed core numbers vs GHz in previous editions?

I just got the following feedback from a FM engineer:

 

 

For your solution, I would invest in disk first, processor speed second, and cores third. You are correct that a single request to FileMaker Server can spawn several threads, but a single request (like a find) cannot be split into multiple threads. In most cases, the limiting factor on Server performance is how fast FMS can read data off of the disk and get it out over the network. 

With hundreds of users, adding cores can do a lot to improve performance, but with just a few users, raw speed is going to be a lot more important.

 

 

****

 

Any comments?

It would be great to see a chart of how the different factors (processor/drive/cores/network) affect the performance for an increasing number of users so we can find the optimum balance for the number of users. Problem is that there are too many variables in the way our FileMaker solutions are developed that may have a bigger influence and negate all other factors!

Consistently the Engineers have said that the hard drive subsystem is the single most important factor.  The SE's echo that in each of their Server Configuration Tech Papers.

 

Steven

I'm shopping around to find a TB2 capable enclosure I can hang on to the MacPro with a RAID-0 SSD pair...

Just a quick update on what I decided on ;-)

 

I got the 3GHz/8 core Macpro with internal SSD, and the Promise Pegasus TB2 enclosure, with 2 RAID-0 SSD and 2 backup standard HD drives in pass-through configuration.

 

I have FM 13 server installed on the internal SSD, the live DB files are on the RAID-0 array SSDs, and the FM backup drives are on the internal (OS) SSD. The internal SSD is backed up to the standard HDs in the Pegasus, and that is eventually stored on a tape BU.

 

The performance is roughly 3x my previous MacPro (2008) FM 11 server (Snow Leopard) with standard internal drives (eg, a complex search across portals etc was 2.5h, now 1h, a large GTRR over 100K records was 3x faster.

One outlier I don't quite understand is one of my backups of a large file (50GB) was about 12hrs, now something like 15 minutes...

 

Anyway - mission accomplished.