WCF/IIS超時是否需要重寫？

Question

最近我一直在WCF的前端，特別是託管在IIS（不是自己託管）做了很多工作。

這只是我，還是有人有問題微調超時值。我將首先提到您需要從拍子中微調的超時時間。

看看下面結合端點值，所有以某種方式或其他涉及超時：

• closeTimeout = 「00:01:00」
• openTimeout =「00:01： 00"
• receiveTimeout = 「00:10:00」
• 的SendTimeout = 「00:01:00」
• MAXBUFFERSIZE = 「999」
• maxBufferPoolSize = 「524288」
• maxReceivedMessageSize = 「999」
• readerQuotas MAXDEPTH = 「32」
• readerQuotas maxStringContentLength = 「8192」
• readerQuotas的MaxArrayLength = 「16384」
• readerQuotas maxBytesPerRead = 「4096」
• readerQuotas maxNameTableCharCount = 「16384」

這些只是客戶端端點配置值，我們甚至還沒有開始，現在爲了讓服務在II中運行S，還需要設置服務器端綁定，它提供與客戶端相同級別的複雜性。

一旦完成，在長時間調用WCF服務期間配置IIS也很重要，否則最終會導致主線程中止。

IIS需要保持禁用狀態，應用程序池還帶有大量的超時值App Pool，這是一個詳細的主題。除此之外，還有另外7個超時值需要特別微調，否則會期望複雜的WCF調用失敗。

對不起，但其他人有沒有聞到老鼠？

我的理解是，基本上（大多數）這些超時值是因信任問題而存在的。我相信，我的意思是「我們不相信服務在合理的時間內完成他們應該做的事情」。 SOA可靠通信的每個方面都是事先不信任的，正因爲如此，我們似乎需要大量的捕獲網絡（超時值）來確保一定程度的可管理性。讓我們面對它，如果我們信任系統及時給出響應，爲什麼需要設置超時值？

我所有這一切的問題是，坦率地說，它回到前面，如果我在我的應用程序中有5個系統通常是可信的並且通常會給出及時的響應。我很沮喪，我仍然需要經歷冗長的定義這些邊界的過程，因爲OOB，WCF/IIS託管失敗。

我發現WCF技術是虛僞的，在網絡演員和營銷演示期間，通常總是會提到WCF允許從實現中更好地抽象，允許開發人員更容易地編寫和部署，並通過「簡單」定義端點能夠專注於業務邏輯，而不是強調架構。在實踐中我發現沒有什麼比事實更能說明問題。有了WCF，您需要深入瞭解服務運行的細節，而且您需要手動進行微調，與ASMX服務中通常部署時沒有太多爭論的情況不同，而且只需要一些IIS微調，甚至很少。

所以我提出的問題是：它只是我還是你們中的任何一個人都有同樣的挫折和觀察？歡迎所有評論！

Answer 1

從哪裏開始？

你必須記住的一點是，WCF服務的架構是獨立於主機應用程序。根據您的場景和需求，您可以在命令行應用程序，WinForms應用程序，Windows服務，IIS，Silverlight，Win32應用程序，MFC應用程序等中託管WCF服務。

因此，WCF基礎架構和託管應用程序基礎結構需要獨立控制和配置。

就你而言，你已經選擇在IIS中託管你的WCF服務。對於廣泛的場景來說，這是一個很好的選擇，但在其他場合選擇不佳。爲什麼？因爲IIS專門爲非常有針對性的場景而構建：接收和發送對短期工作進程的請求並將響應返回給調用者。

「短命」陳述是故意的：IIS主要用作Web服務器。因此默認配置爲充當Web服務器。 Web服務器通常配置爲儘可能快地響應呼叫者。除非工作進程返回響應，否則Web服務器不知道頁面請求產生的工作進程是「繁忙」還是「掛起」。在收到響應之前，Web服務器只能假定工作進程處於「繁忙」狀態。如果工作進程在給定的（可配置的）時間段內沒有響應，那麼Web服務器決定終止工作進程，因爲它可能是掛起的。

因此，在您的場景中，您使用IIS來託管具有特殊要求（即執行長時間運行操作的能力）的非典型應用程序。如果您，應用程序開發人員/管理員知道某些應用程序可能不會返回超過10分鐘，那麼您可以撥入承載您的特例應用程序的工作進程的超時期限。這是一件好事。如果你沒有被賦予這種能力，那麼當你的代碼中的一個bug或數據庫層中的一個緩慢的事情使整個Web服務器癱瘓時，你會尖叫，因爲你的工作進程中沒有NONE時間到。

大部分的邏輯同樣適用於WCF配置設置：

所有設置你注意讓你通過修改其配置設置來控制你的WCF服務的性能特性 - 無需更改任何代碼和/或部署新的位（假設你通過配置文件來配置你的服務，而不是通過代碼來控制這些設置）。

如果您似乎指出，您有WCF服務執行長時間運行的任務，您可以選擇不將它們託管在IIS中，而是將它們託管在Windows服務應用程序中。在這種情況下，您的託管應用程序除了託管您的服務以外，並沒有做任何其他事情，而是恰當地響應啓動和關閉通知。那麼如何控制你的服務處理消息的能力非常大？你將如何控制同時創建的服務實例的數量？你將如何控制WCF等待新服務實例打開和/或關閉的時間？

很高興您有機會改變這些和其他一些設置中的一些/某些/全部設置，並非常容易地控制服務的性能，安全性，可靠性和行爲。這可能會更糟糕 - 您可能完全無法控制您的服務或其主機，並且必須滿足您提供的任何性能特徵。