Search results

The ScaleOut service uses the OpenSSL library for TLS (not Windows schannel), so those registry keys won't have an effect. Version 5.14.1.380 of the ScaleOut service (released 7-Jul-2023) sets the minimum protocol version to TLS 1.2, so it appears that you're running an older version of the...

Hi Caleb, Great question. In the NamedCache library, locks are held on a per-thread basis. (Behind the scenes, the API holds on to a lock ticket for you in thread-local storage.) The idea is that locks can provide consistency across any number of clients, processes, and threads. FYI, the newer...

Yes, that's all that you need to do.

We'll change the service so that it will just log the problem instead of restarting if/when the condition occurs. The next release will be out within the next two weeks.

Hi Nadav, This appears to be the same behavior that one of your associates (royial) reported last year: https://community.scaleoutsoftware.com/threads/usage-of-soss-with-nuget.811/ We're interested to know what happened after the original report from last year--did the restarts continue...

I see, thanks for clarifying. This is a case of the user's session growing larger and larger--this test case will get slower and slower with any out-of-process provider because of how ASP.NET groups a user's session items into one object. All the items in a user's session dictionary are...

I'm afraid don't fully grasp the scenario here--does the slow performance occur only during load tests, or is it when you're manually poking at the site with a web browser (or is the site under other load while you're manually browsing)? Overall memory usage shouldn't affect response times from...

Hi Rob, Which session provider are you using? The traditional one that ships with the main product installer, or one of the newer NuGet providers (sync/async)? Also, a few notes about this test (and session state in general): Session data isn't written back to the ScaleOut service after your...

That's a little surprising. Do you have a "hot object" that's accessed much more frequently than any other? (If so, whatever client cache partition it falls into will get hammered and eventually become a bottleneck... so scaling the number of client cache partitions may not help in that case.)...

Hi, thanks for the update. It would appear that the bottleneck moved out of the connection pool and up into the client cache. This might actually be good progress! Try increasing the number of client cache partitions to reduce the contention there. You can do that through the partitionCount...

No, it's the opposite: you want forceManagedLocking to be set to false to get the new, "optimized" locking behavior.

OK, I've posted Scaleout.Client version 4.2.10 on ScaleOut's development NuGet feed. You'll need to add http://nuget.scaleoutsoftware.com/nuget as a package source and then make sure this source is selected in the NuGet package manager. (See Microsoft’s Package Sources topic for details on...

I applied the locking change to our .NET Core build, but it did not improve performance in our tests--we saw that the performance on .NET Core 5/6 was already very good, even slightly better than the optimized .NET Framework behavior under the same load (500 threads vying for resources from a...

Yes, we'll move forward to get that optimization into .NET Core.

I don't think you'll see a difference in performance of the core library functionality if you upgrade to the latest. Most of the changes since 3.1.4 have involved adding support for advanced features in the service (GeoServer, PMI, etc.). There was one important fix in 4.2.7 involving client...

OK, so you're still running with a whole lot of threads. We can research to see if there's a similar optimization available for the .NET Core build. But, if possible, I would try moving to the async Cache methods and at least test to see if there's an improvement. I'm almost certain it'll help...

A few questions: How many threads do you see blocked on GatewayMultiplexer.GetGatewayFor()? Hundreds? What operating system are you running on? Is it possible for you to move to async calls and keep your app's thread count down? For background, I looked through old support cases and pieced...

Hi Nadav, just a one-week check-in: have you had an opportunity to deploy 1.0.4 and determine whether it helped?

Thank you. The line number appears related to the fix we made, so I think there's a very good chance it's resolved. I cannot say it's fixed with 100% certainty because we still aren't able to repro this particular exception--the error here is a result of corruption that occurred in the cache at...

Hello again Nadav, We found and resolved an issue in the Scaleout.Collections NuGet package that may explain the exception that you reported. Please update your project to use version 1.0.4--we'll be interested to hear if this resolves the issue. Thanks!