Connection pool & ASP.Net

[VirtuallyMike]

Hi,

Love the library - it's been a prototyping dream, honestly, but now
I'm pushing toward a "real" implementation of a project and, I hope
you'll forgive my ignorance, but I'm just not entirely getting how I
ought to use the Threadwisepool stuff in an ASP.Net application.

To give you a little background, say that I have a webservice which
I'm using to expose an API that interacts with Redis. There may be
hundred or (if things go really well) thousands of users hitting the
webservice every second, so I want to be sure that I don't constantly
create/destroy connections to Redis to service their calls...

Do I need to create the ThreadwisePool in the ASP.Net Application or
is it a Singleton of some sort so that I can declare and use it in the
Class that implements the WebService?

I notice in your connection pool sample that you just get an instance
of the client and use it, but there's nothing done to release the
connection other than to let it fall out of scope. Is the sample
complete (i.e. should I be seeing it and saying, "Of course he
obviously omitted call <whatever> to release the connection", because
I'm not all that familiar with object pool implementations and such a
statement is not just coming to me)?

Lastly - is there anything done to limit the size of the pool of
connections (or some ability to tune of the size of the pool)? Maybe
I'm concerned about a scope of activity that just won't be an issue,
but I'm a little concerned that the pool could grow in an unbounded
way until the server begs for mercy or that the connection pool might
not shrink should the demand for connections fall off sharply (for
instance, during an off-hours period of the day). Just wondering what
my options are as far as throttling what it does, and if I need to be
thinking about that sort of thing or if it's sort of magically self-
managing...

Thanks.

[Chakrit Wichian]

Hi, VirtuallyMike!

Sorry for the late reply! Got it while I'm in deep sleep.

It's not your fault that the ThreadwisePool is less than ideal. It's been one of the thing that I had never find time to really fix. On the other hand, I've also started a bit of work on sharing connections globally across all redis instances but it's been really tricky and I havn't had time to hack on Sider for a long while.

I've just got 4-days holiday though so maybe I'll look into it and maybe write a better tutorial/explanation.

If you are concerned about performance, the best way I recommend you to use right now is to use an IoC container to manages the pool of IRedisClient<string> instances -- that way you will have better control of client activations/deactivations.

The way ThreadwisePool works right now is to store clients in a ThreadLocal<WeakReference> which means 2 things : if memory gets low, clients will be disposed automatically and that requests going to the same thread will reuse the same connection to redis. This should works fine for most website cases.

Now to answer some of your questions:

Do I need to create the ThreadwisePool in the ASP.Net Application or

is it a Singleton of some sort so that I can declare and use it in the

Class that implements the WebService?

You should create a ThreadwisePool yourself and share it across the site. It should be used as a Singleton, but that is not done automatically.

I notice in your connection pool sample that you just get an instance

of the client and use it, but there's nothing done to release the

connection other than to let it fall out of scope.

That's intentional. I'll update the code to make it clearer. The thing is that connections are released when the client is disposed (as you'd expect.) But since in this case you want the connection to stay alive and re-used on another request so we're intentionally _not_ disposing it (thus the "pool").

It'll eventually be disposed though (e.g. after a traffic spike) because of the ThreadLocal<WeakReference> storage as explained.

Lastly - is there anything done to limit the size of the pool of

connections (or some ability to tune of the size of the pool)?

Unfortunately none at the moment. It sort of magically self-manging as you say as it relies on the ASP.NET managing the threads. So if ASP.NET runtime kills thread, the client and the connection attached to that thread (via ThreadLocal<> as said) will also be killed.

Personally, though, I believe it will work just fine on most sites as long as ASP.NET is properly configured. But my requirements are not as tough as you guys seem to have so it could just be me.

Let me know if you'd like to see some specific configuration knob implemented that could help in this case.

Or a pull request would be much appreciated :-)

Hope this helps!

- chakrit