IIS 7 and Above
IIS vs VS Cassini tcprecv(s) and EF Caching
Last post Nov 20, 2017 09:26 PM by lextm
Nov 14, 2017 06:05 PM|DevendraBhadauria|LINK
Our development environment uses VS 2010, Silverlight 5.0, .Net framework 4.0, Entity Framework 4.0, WCF Ria Services V1.0 SP2, LINQ. We're observing the following issues in our application deployment to IIS vs Cassini:
- We see many more no. of tcprecv(s) in IIS vs Cassini for a set-of-operations first run, these extra tcprecv(s) are causing a significant difference in the performance numbers though the Data Server and NW behave exactly the same for both Web servers. Are
there some known configuration parameters for TCP/IP that need to tweak in? Ideally IIS should be performing better than Cassini as being full blown Web Server.
- In the second run for the same set-of-operations we see lots of queries don't go to Data Server as being resolved in potentially by EF Caching in Cassini vs reaching all out to Data Server again for IIS. What could cause IIS NOT caching and utilizing EF
results from the previous run? Please share if we need to perform some additional steps.
We are eagerly waiting up for some directions here as we've exhausted our debug and tracing options. Please let us know if additional information or artefacts need to be shared.
Nov 14, 2017 09:23 PM|lextm|LINK
You should really go to an EF forum or general programming site like Stack Overflow to ask such questions.
EF has so many caches,
and its internal logic to control them is complex, so comparing two cases would require more caution on data analysis.
Cassini is a single process web server, so I think your second run can hit caches easily, while IIS is not and its worker process can be shut down or recycled, which can prevent EF caches from working properly. Again, that's just a guess as you showed nothing
about how you set up the testing.
Nov 15, 2017 05:22 AM|DevendraBhadauria|LINK
I'll take the second part of the query to EF forums on SO.
We know caching wouldn't come into the picture for the first run, how would we see more tcprecv(s) for the same Data Server/NW and the same amount of data for IIS.
We're up for sharing artefacts or traces you require.
Nov 16, 2017 05:32 AM|Yuk Ding|LINK
It would be grateful to mark as answer if the reply is helpful.
Nov 20, 2017 05:03 PM|DevendraBhadauria|LINK
Let me rephrase the question, for the first iteration what could cause a significant difference in # of tcprecv(s):
Nov 20, 2017 09:26 PM|lextm|LINK
both Cassini and IIS would use the same native Windows TCP/IP stack?
Nope. They are completely different products, so using different API to talk to Windows TCP/IP stack.
I don't think tcprecv(s) is something you should care at this moment. Focus on the real problem.
I wrote about Cassini a while ago, and as a toy you should never assume what observed from it is useful,