FMSERVER multi threading revised

Apparently FMS18 can utilize more cores depending on concurrency. I understood from what I read that multi user access will profit. How about PSoS calls and DataAPI / REST?
Anyone seeing improvements of scalability?

The actual PSOS or DataAPI call were already spawned in their own thread, if I recall correctly.

The part that benefits you most is that the next step, where the bottleneck used to exist, has been opened up. So when you are doing finds, especially, your users and server-side scripts aren’t competing for the processing resources the same.

What I’ve seen is that PSOS and Users scale about the same. You see a smaller gain on the PSOS side alone, because the other bottlenecks, specifically network, are not involved as much. While I ran my tests using PSOS, there was definitely a boost in performance for finds, on the user side, the gain is more tangible. You can feel it when a lot of users are on. Times when everything would slow down, doesn’t happen now.

2 Likes

Thanks for your observations @jormond As usual I would like to know how the granularity of the newly claimed multi threading works. Apparently it appears that one user’s session will still be one thread only and PSoS are all of all users just one thread same as API?

Please let’s try to collect facts precisely confirmed without assuming. Did Claris officially claim improvements in performance?

With this first version, the performance gains were clear in the keynote and info released with 18. Finds and things related to queries and indexes should be faster, for groups of users. For individual users ( literally only a user or 2 ), it may be slightly slower or about the same.

There is a slight compromise for the change they made to achieve the page locking and multi-thread behavior. Clay said in one of the videos that many performance enhancements have been waiting on this change. Now that it’s made, they can begin working on the other performance enhancements.

Somewhere, I believe Wim Decorte posted some numbers from his testing. Even in areas where things were “slower”, we are talking milliseconds overall. So it’s not a big deal. The gains in more complex finds, and related finds was significant with several users. The more cores, the more benefit you will see.

We tested 18 quite a bit and are using it in production on all 3 of our production servers, and both of our main development servers. I have numbers somewhere. I’ll try to dig them out.

5 Likes

thanks @jormond that matches my findings from under-the-hood presentation. In regards to PSoS execution and DataAPI - it is not clear (at least for me) if multi-threading is in place and how? per user/session or per call? Apparently at least in a WD guide it states that you need to write your own scheduler for execution of consecutive calls which would be indicative for single threading?

Thanks again!

It’s my understanding that PSOS has always spawned in it’s own thread. As for the DataAPI, I’m less clear on that. I’m not sure how that equates with how the web publishing engine functions, or if it’s even part of that.