Bạn hiện đang ngoại tuyến, hãy chờ internet để kết nối lại

Ganh đua, hiệu suất tầm nhìn thấp và deadlocks khi bạn thực hiện cuộc gọi đến bản ghi Dịch vụ Web từ một ứng dụng ASP.NET

QUAN TRỌNG: Bài viết này được dịch bằng phần mềm dịch máy của Microsoft chứ không phải do con người dịch. Microsoft cung cấp các bài viết do con người dịch và cả các bài viết do máy dịch để bạn có thể truy cập vào tất cả các bài viết trong Cơ sở Kiến thức của chúng tôi bằng ngôn ngữ của bạn. Tuy nhiên, bài viết do máy dịch không phải lúc nào cũng hoàn hảo. Loại bài viết này có thể chứa các sai sót về từ vựng, cú pháp hoặc ngữ pháp, giống như một người nước ngoài có thể mắc sai sót khi nói ngôn ngữ của bạn. Microsoft không chịu trách nhiệm về bất kỳ sự thiếu chính xác, sai sót hoặc thiệt hại nào do việc dịch sai nội dung hoặc do hoạt động sử dụng của khách hàng gây ra. Microsoft cũng thường xuyên cập nhật phần mềm dịch máy này.

821268
Triệu chứng
Khi bạn thực hiện cuộc gọi đến bản ghi Dịch vụ Web từ một ứng dụng Microsoft ASP.NET, bạn có thể gặp phải ganh đua, hiệu suất tầm nhìn thấp và deadlocks. Khách hàng có thể báo cáo rằng yêu cầu ngừng đáp ứng (hoặc "treo") hoặc mất một thời gian rất dài để thực hiện. Nếu một bế tắc nghi ngờ, trình công nhân có thể được tái chế. Bạn có thể nhận được các thông báo sau đây trong Nhật ký sự kiện ứng dụng.
  • Nếu bạn đang sử dụng Internet Information Services (IIS) 5.0, bạn nhận được các thông báo sau đây trong Nhật ký ứng dụng:

       Event Type:     Error   Event Source:   ASP.NET 1.0.3705.0   Event Category: None   Event ID:       1003   Date:           5/4/2003   Time:           6:18:23 PM   User:           N/A   Computer:       <ComputerName>   Description:      aspnet_wp.exe  (PID: <xxx>) was recycled because it was suspected to be in a deadlocked state.      It did not send any responses for pending requests in the last 180 seconds.

  • Nếu bạn đang sử dụng IIS 6.0, bạn nhận được các thông báo sau đây trong Nhật ký ứng dụng:

       Event Type:     Warning   Event Source:   W3SVC-WP   Event Category: None   Event ID:       2262   Date:           5/4/2003   Time:           1:02:33 PM   User:           N/A   Computer:       <ComputerName>   Description:      ISAPI 'C:\Windows\Microsoft.net\Framework\v.1.1.4322\aspnet_isapi.dll' reported itself as      unhealthy for the following reason: 'Deadlock detected'.

  • Nếu bạn đang sử dụng IIS 6.0, bạn nhận được các thông báo sau đây trong các bản ghi hệ thống:

       Event Type:     Warning   Event Source:   W3SVC   Event Category: None   Event ID:       1013   Date:           5/4/2003   Time:           1:03:47 PM   User:           N/A   Computer:       <ComputerName>   Description:      A process serving application pool 'DefaultAppPool' exceeded time limits during shut down.      The process id was '<xxxx>'.

Bạn cũng có thể nhận được lỗi ngoại lệ sau thông báo khi bạn thực hiện một cuộc gọi đến phương pháp HttpWebRequest.GetResponse :
"System.InvalidOperationException: Đã có không đủ chủ đề miễn phí trong các đối tượng ThreadPool để hoàn thành những hoạt động."
Bạn cũng có thể nhận được thông báo lỗi sau ngoại lệ trong trình duyệt:
"HttpException (0x80004005): yêu cầu hẹn giờ ra."
Lưu ý Bài viết này cũng áp dụng cho các ứng dụng mà làm cho yêu cầu HttpWebRequest trực tiếp.
Nguyên nhân
Vấn đề này có thể xảy ra bởi vì ASP.NET giới hạn số nhân viên chủ đề và chủ đề cổng hoàn thành một cuộc gọi có thể sử dụng để thực hiện yêu cầu.

Thông thường, một cuộc gọi đến một bản ghi Dịch vụ Web sử dụng một nhân viên sợi để thực thi mã gửi yêu cầu và một hoàn thành cảng chủ đề nhận được gọi lại từ các bản ghi Dịch vụ Web. Tuy nhiên, nếu các yêu cầu được chuyển hướng hoặc yêu cầu xác thực, các cuộc gọi có thể sử dụng nhiều như hai nhân viên chủ đề và hai hoàn thành cảng chủ đề. Vì vậy, bạn có thể thải ThreadPool được quản lý khi nhiều Web bản ghi dịch vụ cuộc gọi xảy ra cùng một lúc.

Ví dụ, giả sử rằng ThreadPool được giới hạn đến 10 nhân viên chủ đề và chủ đề 10 nhân viên hiện đang thực thi mã mà chờ đợi cho một gọi lại để thực hiện. Gọi lại không bao giờ có thể thực hiện, bởi vì bất kỳ mục công việc nào được xếp hàng đợi để ThreadPool đang bị chặn cho đến khi một chủ đề trở nên có sẵn.

Một nguồn tiềm năng của ganh đua là tham số maxconnection không gian tên System.Net sử dụng để hạn chế số lượng kết nối. Nói chung, giới hạn này hoạt động như mong đợi. Tuy nhiên, nếu nhiều ứng dụng cố gắng để làm cho nhiều yêu cầu một địa chỉ IP duy nhất tại cùng một thời gian, chủ đề có thể phải chờ đợi cho kết nối có sẵn.
Giải pháp
Để giải quyết những vấn đề này, bạn có thể điều chỉnh các tham số sau đây trong các tập tin Machine.config để tốt nhất phù hợp với tình hình của bạn:
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • maxconnection
  • executionTimeout
Để thành công giải quyết những vấn đề này, có những hành động sau đây:
  • Giới hạn số lượng yêu cầu ASP.NET có thể thực hiện tại đồng thời khoảng 12 cho mỗi CPU.
  • Cho phép web site bản ghi dịch vụ callbacks để tự do sử dụng chủ đề trong ThreadPool.
  • Chọn một giá trị thích hợp cho tham số maxconnections . Cơ sở lựa chọn của bạn về số lượng các địa chỉ IP và AppDomains được sử dụng.
Lưu ý Các khuyến nghị để giới hạn số lượng yêu cầu ASP.NET-12 mỗi CPU là một chút tùy ý. Tuy nhiên, các giới hạn này đã chứng minh để làm việc tốt cho Hầu hết các ứng dụng.

maxWorkerThreadsmaxIoThreads

ASP.NET sử dụng cài đặt chuyên biệt hai cấu hình sau để hạn chế số lượng nhân viên chủ đề và chủ đề hoàn thành tối đa sử dụng:
<processModel maxWorkerThreads="20" maxIoThreads="20">
Tham số maxWorkerThreads và tham số maxIoThreads là hoàn toàn nhân số CPU. Cho Ví dụ, nếu bạn có hai bộ vi xử lý, số nhân viên chủ đề, tối đa là Các tùy chọn sau:
2 * maxWorkerThreads

minFreeThreadsminLocalRequestFreeThreads

ASP.NET cũng chứa các cấu hình sau cài đặt chuyên biệt xác định bao nhiêu nhân viên chủ đề và hoàn thành cảng chủ đề phải có sẵn để Bắt đầu một yêu cầu từ xa hoặc một yêu cầu địa phương:
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
Nếu không có đầy đủ các chủ đề có sẵn, yêu cầu được xếp hàng đợi cho đến khi đủ chủ đề được miễn phí để thực hiện yêu cầu. Vì vậy, ASP.NET sẽ không thực hiện nhiều hơn số yêu cầu, sau cùng một lúc:
(maxWorkerThreads*số CPU)-minFreeThreads
Lưu ý Tham số minFreeThreads và tham số minLocalRequestFreeThreads là không hoàn toàn nhân số CPU.

minWorkerThreads

Như của ASP.NET 1.0 Service Pack 3 và ASP.NET 1.1, ASP.NET cũng chứa các tập cấu hình sau đây xác định như thế nào nhiều nhân viên chủ đề có thể được thực hiện có sẵn ngay lập tức để phục vụ một từ xa yêu cầu.
<processModel minWorkerThreads="1">
Chủ đề đó được điều khiển bởi điều này thiết lập có thể được tạo ra tại một tốc độ nhanh hơn nhiều so với chủ đề của công nhân được tạo ra từ các CLR mặc định "chủ đề-chỉnh" khả năng. cài đặt chuyên biệt này cho phép ASP.NET yêu cầu bản ghi dịch vụ có thể đột nhiên điền vào hàng đợi yêu cầu ASP.NET do một hổn trên một kết thúc trở lại máy chủ, một burst đột ngột của các yêu cầu từ phía khách hàng, hoặc một cái gì đó tương tự mà sẽ gây ra sự gia tăng đột ngột trong số các yêu cầu trong hàng đợi. Các giá trị mặc định cho tham số minWorkerThreads là 1. Chúng tôi khuyên bạn đặt giá trị cho tham số minWorkerThreads để giá trị sau đây.
minWorkerThreads = maxWorkerThreads / 2
theo mặc định, tham số minWorkerThreads là không hiện diện trong cả hai tập tin Web.config hoặc các tập tin Machine.config. cài đặt chuyên biệt này hoàn toàn nhân với số CPU.

maxconnection

Tham số maxconnection xác định làm thế nào nhiều kết nối có thể được thực hiện cho một địa chỉ IP cụ thể. Tham số này sẽ xuất hiện như sau:
<connectionManagement>    <add address="*" maxconnection="2">    <add address="http://65.53.32.230" maxconnection="12"></connectionManagement>
Nếu mã của ứng dụng tài liệu tham khảo các ứng dụng bằng tên máy (ứng dụng) phục vụ thay vì địa chỉ IP, tham số này sẽ xuất hiện như sau:
<connectionManagement>    <add address="*" maxconnection="2">    <add address="http://hostname" maxconnection="12"></connectionManagement>
Cuối cùng, nếu các ứng dụng được lưu trữ trên một cổng khác hơn so với 80, các tham số có bao gồm các cổng không chuẩn trong URI, tương tự như sau đây:
<connectionManagement>    <add address="*" maxconnection="2">    <add address="http://hostname:8080" maxconnection="12"></connectionManagement>
Các cài đặt chuyên biệt cho các tham số được thảo luận trước đó trong bài viết này là tất cả ở cấp độ quá trình. Tuy nhiên, cài đặt chuyên biệt tham số maxconnection áp dụng đến mức độ AppDomain. theo mặc định, bởi vì thiết đặt này áp dụng cho mức độ AppDomain, bạn có thể tạo tối đa hai kết nối đến một địa chỉ IP cụ thể từ mỗi AppDomain ở của bạn quá trình.

executionTimeout

ASP.NET sử dụng các tập cấu hình sau đây để giới hạn thời gian thực hiện yêu cầu:
<httpRuntime executionTimeout="90"/>
Bạn cũng có thể thiết lập các giới hạn này bằng cách sử dụng các tài sản Server.ScriptTimeout .

Lưu ý Nếu bạn tăng giá trị của tham số executionTimeout , bạn cũng có thể cần phải sửa đổi processModel responseDeadlockInterval cài đặt chuyên biệt tham số.

Khuyến nghị

Các thiết đặt được khuyến cáo trong phần này có thể không làm việc cho Tất cả các ứng dụng. Tuy nhiên, các thông tin bổ sung sau có thể giúp bạn thực hiện những điều chỉnh thích hợp.

Nếu bạn đang làm cho một web site bản ghi dịch vụ gọi đến một địa chỉ IP duy nhất từ mỗi trang ASPX, Microsoft khuyến cáo bạn nên sử dụng các cài đặt chuyên biệt cấu hình sau:
  • Thiết lập giá trị của tham số maxWorkerThreads và tham số maxIoThreads đến 100.
  • Thiết lập giá trị của tham số maxconnection để 12 *N (nơi N là số CPU mà bạn có).
  • Thiết lập giá trị của tham số minFreeThreads để 88 *N và các tham số minLocalRequestFreeThreads để76 *N.
  • Thiết lập giá trị của minWorkerThreads đến 50. Hãy nhớ rằng, minWorkerThreads không phải là trong tập tin cấu hình theo mặc định. Bạn phải thêm nó.
Một số những khuyến nghị liên quan đến một công thức đơn giản mà liên quan đến số của CPU trên một máy chủ. Biến đại diện cho số CPU trong các công thức là N. Đối với các cài đặt chuyên biệt, nếu bạn có hyperthreading được kích hoạt, bạn phải sử dụng số lượng hợp lý CPU thay vì số lượng vật lý CPU. Ví dụ, nếu bạn có một máy chủ 4-bộ xử lý với hyperthreading kích hoạt, sau đó giá trị của N trong các công thức sẽ có 8 thay vì 4.

Lưu ý Khi bạn sử dụng cấu hình này, bạn có thể thực hiện tối đa là 12 ASP.NET yêu cầu mỗi CPU tại cùng một thời gian bởi vì 100-88 = 12. Vì vậy, ít 88 *N nhân viên chủ đề và 88 *N hoàn thành cảng chủ đề có sẵn cho các ứng dụng khác (chẳng hạn như Web bản ghi dịch vụ callbacks).

Ví dụ, bạn có một máy chủ với bốn bộ vi xử lý và hyperthreading được kích hoạt. Dựa trên các công thức này, bạn sẽ sử dụng các giá trị sau cho các cài đặt chuyên biệt cấu hình được đề cập trong bài viết này.
<system.web>	<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/>	<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/></system.web><system.net>	<connectionManagement>		<add address="[ProvideIPHere]" maxconnection="96"/>	</connectionManagement></system.net>

Ngoài ra, khi bạn sử dụng cấu hình này, 12 kết nối có sẵn mỗi CPU cho địa chỉ IP cho mỗi AppDomain. Vì vậy, trong những điều sau đây trường hợp, rất ít ganh đua xảy ra khi yêu cầu đang chờ đợi kết nối, và ThreadPool không phải kiệt sức:
  • Các web site lưu trữ chỉ có một ứng dụng (AppDomain).
  • Mỗi yêu cầu cho một trang ASPX làm cho một yêu cầu bản ghi Dịch vụ Web.
  • Tất cả yêu cầu phải cùng một địa chỉ IP.
Liên quan Tuy nhiên, khi bạn sử dụng cấu hình này, kịch bản mà đến một trong những điều sau đây có thể sẽ sử dụng quá nhiều kết nối:
  • Yêu cầu phải nhiều địa chỉ IP.
  • Yêu cầu là chuyển hướng (mã trạm đậu 302).
  • Yêu cầu yêu cầu xác thực.
  • Yêu cầu được thực hiện từ nhiều AppDomains.
Trong những tình huống, nó là một ý tưởng tốt để sử dụng một giá trị thấp nhất tham số maxconnection và cao hơn giá trị cho tham số minFreeThreads và tham số minLocalRequestFreeThreads .
Tình trạng
Điều này hành vi là do thiết kế.
Thông tin thêm
Nếu bạn đang gặp hiệu suất tầm nhìn thấp và ganh đua trên IIS 7.0 cùng với ASP.NET, đi đến blog Microsoft sau đây:
Tham khảo
Để biết thêm chi tiết, hãy vào web site Microsoft Developer Network (MSDN) sau đây:

Cảnh báo: Bài viết này đã được dịch tự động

Thuộc tính

ID Bài viết: 821268 - Xem lại Lần cuối: 02/06/2013 00:50:00 - Bản sửa đổi: 3.0

  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
  • kbprb kbmt KB821268 KbMtvi
Phản hồi