DbContext/Ninject相關性GetService緩慢SingleOrDefault負載測試

我很抱歉提前對長篇文章，因爲我一直在收集診斷，但似乎不能把我的手指放在這個問題上。DbContext/Ninject相關性GetService緩慢SingleOrDefault負載測試

EF6 /網絡API 2

首先，我注意到一個緩慢運行的端點和負荷下測試得到的更糟。

代碼：

//configuration 
kernel.Bind<T>() 
.To<T>() 
.InTransientScope() 

//Caller elsewhere in code base 
public http.IDependencyScope BeginScope() 
{ 
    return new NinjectScope(_kernel.BeginBlock()); 
} 


public class NinjectScope : IDependencyScope 
{ 
    public object GetService(Type serviceType) 
    { 
    Debug.WriteLine("COREIOC_Enter GetService Timein: {0}", DateTime.Now.ToLongTimeString()); 
    Stopwatch coreIOC = new Stopwatch(); 
    coreIOC.Start(); 

    IRequest request = resolutionRoot.CreateRequest(serviceType, null, new Parameter[0], true, true); 
    Debug.WriteLine(string.Format("COREIOC_Complete CreateRequest Elapsed: {0}", coreIOC.Elapsed)); 

    var abc = resolutionRoot.Resolve(request); 
    Debug.WriteLine(string.Format("COREIOC_Resolve Elapsed: {0}", coreIOC.Elapsed)); 

    var xyz = abc.SingleOrDefault(); 
    Debug.WriteLine(string.Format("COREIOC_SingleDef Resolve Elapsed: {0}", coreIOC.Elapsed)); 

    coreIOC.Stop(); 
    Debug.WriteLine(string.Format("COREIOC_Exit Elapsed: {0}", coreIOC.Elapsed)); 

    return xyz; 
    } 
}

調試輸出：（注意SingleDef是4秒）

COREIOC_Enter GetService Timein: 7:15:56 AM: 
COREIOC_Complete CreateRequest Elapsed: 00:00:00.0008914 
COREIOC_Resolve Elapsed: 00:00:00.0032197  
COREIOC_SingleDef Resolve Elapsed: 00:00:04.4787988 
COREIOC_Exit Elapsed: 00:00:04.4803695

有趣的後續調用顯示此「旋轉起來」的時間消失了

COREIOC_Enter GetService Timein: 7:27:08 AM: 
COREIOC_Complete CreateRequest Elapsed: 00:00:00.0000266 
COREIOC_Resolve Elapsed: 00:00:00.0018957 
COREIOC_SingleDef Resolve Elapsed: 00:00:00.0307401 
COREIOC_Exit Elapsed: 00:00:00.0354408

所以這將是一個打開和關閉的情況下除非下一個負載測試中的端點表示EVERY呼叫4秒的延遲。（例如同時250試運行將顯示每個人服用4+秒）。

手寫負載測試代碼：

public override IEnumerator<WebTestRequest> GetRequestEnumerator() 
{ 
    WebTestRequest request6 = new WebTestRequest("http://localhost:57874/api/acts/10553697"); 
    request6.Timeout = 120; 
    request6.Method = "GET"; 
    request6.Headers.Add(new WebTestRequestHeader("Authorization", "Bearer h0aHdT6...")); 
    request6.Headers.Add(new WebTestRequestHeader("Accept","application/...")); 
    request6.Headers.Add(new WebTestRequestHeader("ContentType", "application/json")); 
    request6.ValidateResponse += new EventHandler<ValidationEventArgs>(request6_ValidateResponse); 
    yield return request6; 
    request6 = null; 
}

所以

是我的負載測試不正確或，
我的EF 6的設置不正確或，
是我的對象重用不正確的，或者
是有proble m與我實際使用SingleOrDefault？

我一直在通過ninject實例化的對象的構造函數，並沒有看到它們導致延遲。

我的確遇到過SO post，作爲一名PluralSight粉絲，我能夠立即訪問課程。然而，這是一個七小時的課程，最後我不確定這是EF造成延誤。

來源

2015-02-09 GPGVM

對不起，任何人關注。我想通了，但忘了在這裏更新。

所以你可以說問題出在Ninject上......但是你也可以做出一個強有力的例子，那就是我們的設計是問題所在。

在一天結束時，我會說這是我們的設計是問題所在。 Ninject的一點靈活性可能會讓設計不再成爲一個問題，但如果一個糟糕的設計從未出現，那麼它的設計仍然很糟糕？

無論如何，我們的終端在他們執行的操作中是靈活的。這很好，除了再加上Ninject所有的東西，即使它不是必需的。

例如，一個端點可能有13個注入對象，但是對於給定的操作只需要3個（其他10個將被其他消費者使用）。

不管只需要3個Ninject會實例化所有的13分鐘和10分鐘以下的750分鐘恆定負載...這是很多JITting正在進行。

因此，爲了更具體的目的，爆發了幾個終點，並且jit時間急劇下降。

從上面的例子：

13噴射在一端點對象成爲：

3注入對象
5噴射的對象
4噴射的對象
3個注入對象

因此，終點1-4不等於13，因爲現在有一些冗餘。同樣的對象是通過一些端點注入的，但是在一天結束時，所有的東西都會像我們所期望的那樣在負載下運行。

來源

2015-04-01 17:18:34 GPGVM

DbContext/Ninject相關性GetService緩慢SingleOrDefault負載測試

回答

相關問題