RE: Code accessing HttpContext.Current

[Louis DeJardin]

Maybe threadpool min thread counts need to be boosted? The exe's defaults are pretty low, I believe, so you might be hitting the add-more-threads-slowly mode in exe with the sudden concurrency?

Sent from my Windows Phone

---

From: Tim Schmidt
Sent: 3/18/2013 1:33 PM
To: net-http-a...@googlegroups.com
Subject: Re: Code accessing HttpContext.Current

Just to followup from the call on performance, there's definitely some contention going on somewhere.  Upping the ServicePointManager stuff (either in config or code) didn't seem to matter.  I'm definitely not ruling out my code, but it's odd that I don't see any issues under IIS.  Here are the perf numbers I see on my local dev box:

Katana

  - 25 threads, 50 times: 95.89 sec

  - 15 threads, 50 times: 90.56 sec

IIS

  - 25 threads, 50 times: 37.20 sec

  - 15 threads, 50 times: 25.20 sec

When I ran 15x50 under Katana, I definitely saw bursts of 15 go through at a time, that's what made it seem like contention.  I'm not sure where I should go from here.  I may try doing some profiling to see if I can figure anything out.

On Monday, March 18, 2013 11:13:34 AM UTC-5, Tim Schmidt wrote:

I ended up solving this by creating a context object that captures the headers I need.  Since I'm using WebApi, I always got a correctly populated ControllerContext either way.  So I made an action filter that looks at that, populates one of my context objects, and sets a static using the method you said before (CallContext.SetLogicalData).  That way my backend component, regardless of the environment I'm running in, can get at the context for the current request.

On Thursday, March 14, 2013 3:55:02 PM UTC-5, Tim Schmidt wrote:

Thought I had a working implementation but now I'm hitting difficulties because the headers dictionary that Katana uses isn't marked as Serializable.  Argh!

I know this seems icky but it seems like my use case isn't that outlandish.  I have a REST service and I need a component I use makes other REST calls as a result.  There are certain HTTP headers that I need to carry forward.  Is there a better solution?

On Thursday, March 14, 2013 2:14:19 AM UTC-5, Louis DeJardin wrote:

That's true, though, there's an awfully short supply of information out there.

On Wed, Mar 13, 2013 at 8:07 PM, Chris R <trat...@hotmail.com> wrote:

The most up to date middleware pattern samples can be found here:

https://github.com/Tratcher/owin-samples/blob/master/MiddlewarePatterns/Startup.cs

There are also a handful of Katana samples on http://aspnet.codeplex.com/.

Let me know if there are major any major gaps.

---

Date: Wed, 13 Mar 2013 13:56:59 -0700
From: t...@schmidthole.com
To: net-http-a...@googlegroups.com
Subject: Re: Code accessing HttpContext.Current

N00b question.  Documentation on Owin/Gate/Katana seems scarce at best and the samples are littered with extension methods that either don't exist anymore or that are marked internal.  Is there some guidance on how to create middleware components?

In regards to my original question, I noticed that my ControllerContext (where I'm using my component from) is populated both under asp.net and katana, so I may just use that to call into my component.  Either by passing the components to each method (which seems ugly) or by feeding them into IoC or something... not sure yet.

On Tuesday, March 12, 2013 3:01:36 PM UTC-5, Louis DeJardin wrote:

Ouch, evil!

Well, one thing you could consider is re-create a pseudo-static property you could access. So if you made a public static IDict<string,object> OwinHttpContext.Current property, and a middleware class which set it going in and cleared it coming out, then your component could use that instead to get the "current" environment.

The tricky part when you implement the Current get/set methods is where to store the value. Thread static breaks down if any of the task work is async - but you might have some of the apis like CallContext.LogicalSetData/LogicalGetData. I believe those values will flow along even if you are async thread-hopping. 

On Tuesday, March 12, 2013 12:50:22 PM UTC-7, Tim Schmidt wrote:

I have a web service that's already written using conventional WebApi under IIS.  I'm trying to make it run under Katana.  The one little problem I'm having is that I have a gateway component deep down (retrieved via IoC) that looks at request headers via HttpContext.Current.  Yes, I know that's not ideal from a testability standpoint, but it was somewhat of a late-in-the-game hack.  But as you could imagine, that's causing me trouble under Katana which doesn't populate HttpContext.Current.

So how can I access headers from down there?

--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstrac...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstrac...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstrac...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tim Schmidt]

Bumping up the min thread count to 32 and max to 100 helped a little but not much.  It got my 25x50 test from ~93sec down to ~80sec.  Trying to rule out db connection pool contention, I also tried adding "Max Pool Size=100" to my db connection string and that helped a little as well.  That got my 25x50 test down to about 68sec although I tried running the test a second time and started getting timeouts getting a connection from the pool.  So that's curious...

To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsub...@googlegroups.com.

[Tim Schmidt]

Ok, my problem is definitely at the database layer.  Like I said originally, my service basically does two things: pulls some data from the db and then fills in some data from an external REST service.  The db access is done using the new async features in EF6a3 and my REST calls are using the async methods in HttpClient.  I created a test REST method that skips the db access and it shaved the time of my 25x50 test all the way down to ~17-18sec.  That's less than half of time I was seeing under IIS.

Now I need to figure out what the bottleneck is at the db layer!  Unfortunately, I need EF6 in order to have more control over the underlying connection.

[Tim Schmidt]

Quick update: I posted my situation to the EF discussions and someone from that team is going to look into it...

http://entityframework.codeplex.com/discussions/437339