2013-03-28 40 views
8

Tôi bắt đầu sử dụng dapper.net một thời gian trước đây vì lý do hiệu suất và tôi thực sự thích tính năng tham số được đặt tên so với chỉ chạy "ExecuteQuery" trong LINQ to SQL.Các vấn đề thời gian chờ lạ với Dapper.net

Nó hoạt động tốt cho hầu hết các truy vấn nhưng đôi khi tôi nhận được một số thời gian chờ rất kỳ lạ. Điều kỳ lạ nhất là thời gian chờ này chỉ xảy ra khi SQL được thực hiện thông qua lệnh. Nếu tôi lấy truy vấn được thực hiện được sao chép từ profiler và chỉ cần chạy nó trong Management Studio, nó nhanh và hoạt động hoàn hảo. Và nó không chỉ là một vấn đề tạm thời. Truy vấn liên tục hết thời gian chờ thông qua người lập bản đồ và luôn hoạt động tốt trong Management Studio.

exec sp_executesql N'SELECT Item.Name,dbo.PlatformTextAndUrlName(Item.ItemId) As PlatformString,dbo.MetaString(Item.ItemId) As MetaTagString, Item.StartPageRank,Item.ItemRecentViewCount 
        NAME_SRCH.RANK as NameRank, 
        DESC_SRCH.RANK As DescRank, 
        ALIAS_SRCH.RANK as AliasRank, 
        Item.itemrecentviewcount, 
        (COALESCE(ALIAS_SRCH.RANK, 0)) + (COALESCE(NAME_SRCH.RANK, 0)) + (COALESCE(DESC_SRCH.RANK, 0)/20) + Item.itemrecentviewcount/4 + ((CASE WHEN altrank > 60 THEN 60 ELSE altrank END) * 4) As SuperRank 
        FROM dbo.Item 
        INNER JOIN dbo.License on Item.LicenseId = License.LicenseId 

        LEFT JOIN dbo.Icon on Item.ItemId = Icon.ItemId 
        LEFT OUTER JOIN FREETEXTTABLE(dbo.Item, name, @SearchString) NAME_SRCH ON 
        Item.ItemId = NAME_SRCH.[KEY] 
        LEFT OUTER JOIN FREETEXTTABLE(dbo.Item, namealiases, @SearchString) ALIAS_SRCH ON 
        Item.ItemId = ALIAS_SRCH.[KEY] 
        INNER JOIN FREETEXTTABLE(dbo.Item, *, @SearchString) DESC_SRCH ON 
        Item.ItemId = DESC_SRCH.[KEY] 
        ORDER BY SuperRank DESC OFFSET @Skip ROWS FETCH NEXT @Count ROWS ONLY',N'@Count int,@SearchString nvarchar(4000),@Skip int',@Count=12,@SearchString=N'box,com',@Skip=0 

Đó là truy vấn tôi sao chép được dán từ SQL Profiler. Tôi thực hiện nó như thế này trong mã của tôi.

  using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["Conn"].ToString())) { 
      connection.Open(); 
      var items = connection.Query<MainItemForList>(query, new { SearchString = searchString, PlatformId = platformId, _LicenseFilter = licenseFilter, Skip = skip, Count = count }, buffered: false); 
      return items.ToList(); 
     } 

Tôi không biết bắt đầu từ đâu. Tôi cho rằng phải có một cái gì đó đang xảy ra với dapper vì nó hoạt động tốt khi tôi chỉ thực thi mã.

Như bạn có thể thấy trong ảnh chụp màn hình này. Đây là cùng một truy vấn được thực hiện thông qua mã đầu tiên và sau đó thông qua Management Studio.

enter image description here

tôi cũng có thể thêm rằng điều này chỉ (tôi nghĩ) xảy ra khi tôi có hai hoặc nhiều từ hoặc khi tôi có một "stop" char trong chuỗi tìm kiếm. Vì vậy, nó có thể có một cái gì đó todo với tìm kiếm văn bản đầy đủ nhưng tôi không thể tìm ra cách để gỡ lỗi nó vì nó hoạt động hoàn hảo từ Management Studio.

Và để làm cho vấn đề trở nên tồi tệ hơn, nó hoạt động tốt trên máy chủ cục bộ của tôi với một cơ sở dữ liệu gần như giống hệt cả từ mã và từ Management Studio.

Trả lời

7

Dapper không gì khác ngoài trình bao bọc tiện ích trên ado.net; nó không thay đổi cách hoạt động của ado.net. Nó âm thanh với tôi rằng vấn đề ở đây là "làm việc trong ssms, thất bại trong ado.net". Đây không phải là duy nhất: thỉnh thoảng thỉnh thoảng tìm thấy điều này. ứng cử viên có khả năng:

  • "đặt" tùy chọn: những có giá trị mặc định khác nhau trong ado.net - và có thể ảnh hưởng đến hiệu suất đặc biệt là nếu bạn có những thứ như tính + vẫn kiên trì + cột được lập chỉ mục - nếu "đặt" tùy chọn không tương thích nó có thể quyết định nó không thể sử dụng giá trị được lưu trữ, do đó không phải là chỉ mục - và thay vì quét bảng và tính toán lại. Có những kịch bản tương tự khác.
  • mức cô lập/chặn giao dịch/tải giao dịch; chạy một cái gì đó trong ssms không tái tạo toàn bộ tải hệ thống tại thời điểm đó trong thời gian
  • kế hoạch truy vấn được lưu trong bộ nhớ cache: đôi khi một kế hoạch duff được lưu trữ và sử dụng; chạy từ ssms thường sẽ buộc một kế hoạch mới - mà tự nhiên sẽ được điều chỉnh cho các thông số bạn đang sử dụng trong thử nghiệm của bạn. Cập nhật tất cả số liệu thống kê chỉ mục của bạn, v.v. và xem xét việc thêm gợi ý truy vấn "tối ưu hóa"
+0

Xin lỗi vì trả lời chậm trễ của tôi, nhưng nó là loại khó để kiểm tra. Dù sao tôi nghĩ rằng nó đã làm với các kế hoạch truy vấn được lưu trữ. Tôi đã có thời gian ra tại địa phương ngay bây giờ và khởi động lại máy chủ và sau đó nó làm việc. Tôi đã thử thêm một "OPTIMIZE FOR" thingy ngay bây giờ. Hy vọng rằng sẽ giúp đỡ. Cảm ơn vì những hiểu biết! – Olaj

1

Có thể là vấn đề đặt thời gian chờ lệnh trong Dapper. Dưới đây là ví dụ về cách điều chỉnh thời gian chờ của lệnh trong Dapper: Setting Command Timeout in Dapper

6

Trong ADO là giá trị mặc định cho thời gian chạy thử 30 giây, trong Management Studio vô cùng. Điều chỉnh thời gian chờ lệnh để gọi Truy vấn <>, xem bên dưới.

var param = new { SearchString = searchString, PlatformId = platformId, _LicenseFilter = licenseFilter, Skip = skip, Count = count }; 
var queryTimeoutInSeconds = 120; 
using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["Conn"].ToString())) 
{ 
    connection.Open(); 
    var items = connection.Query<MainItemForList>(query, param, commandTimeout: queryTimeoutInSeconds, buffered: false); 
    return items.ToList(); 
} 

Xem thêm SqlCommand.CommandTimeout Property on MSDN

Các vấn đề liên quan