HttpWebRequest läuft langsam zuerst innerhalb SQLCLR

Question

Wenn Sie eine HttpWebRequest innerhalb einer gespeicherten CLR-Prozedur (gemäß dem folgenden Code), der erste Aufruf nach dem Sql Server ist (neu) gestartet oder nach einem bestimmten (aber unbestimmten) Zeitraum von Die Zeit wartet beim GetResponse() -Methodenaufruf ziemlich lange.

Gibt es eine Möglichkeit, dies zu beheben, die nicht einen "Hack" wie einen Sql Server Agent Job alle paar Minuten ausgeführt wird, um sicherzustellen, dass der erste "langsame" Anruf vom Agenten und nicht gemacht wird "echter" Produktionscode?

function SqlString MakeWebRequest(string address, string parameters, int connectTO) 
{ 
    SqlString returnData; 
    HttpWebRequest request = (HttpWebRequest)WebRequest.Create(String.Concat(address.ToString(), "?", parameters.ToString())); 
    request.Timeout = (int)connectTO; 
    request.Method = "GET"; 
    using (WebResponse response = request.GetResponse()) 
    { 
    using (Stream responseStream = response.GetResponseStream()) 
    { 
     using (StreamReader reader = new StreamReader(responseStream)) 
     { 
     SqlString responseFromServer = reader.ReadToEnd(); 
     returnData = responseFromServer; 
     } 
    } 
    } 
    response.Close(); 

    return returnData; 
} 

(Fehlerbehandlung und anderen nicht-kritischen Code hat ben der Kürze entfernt)

---

Siehe auch this Sql Server forums thread.

Answer 1

Das war ein Problem für mich HttpWebRequest zunächst mit. Es ist wegen der Klasse, die nach einem zu verwendenden Proxy sucht. Wenn Sie den Wert Proxy des Objekts auf null/Nothing festlegen, wird es direkt zip.

Answer 2

Es gibt immer eine Verzögerung, wenn SQLCLR zum ersten Mal die erforderlichen Baugruppen lädt. Das sollte nicht nur für Ihre Funktion MakeWebRequest der Fall sein, sondern auch für eine beliebige .NET-Funktion in der SQLCLR.

Answer 3

HttpWebRequest ist Teil der System.Net-Baugruppe, die nicht Teil der supported libraries ist. Ich würde empfehlen, stattdessen die Bibliothek System.Web.Services zu verwenden, um Webdienstaufrufe von innerhalb des SQLCLR auszuführen.

Answer 4

Nicht sicher, aber wenn die Verzögerung lange genug, dass erste DNS-Lookups der Schuldige sein könnte? (wie lange ist die Verzögerung Vers eines normalen Anruf?)

und/oder

Ist das URI intern im Netzwerk/oder ein anderes internes Netzwerk?

Ich habe einige seltsame Netzwerkverzögerungen verwenden, Lastausgleich Profile in einem Netzwerk gesehen, die nicht Setup richtig ist, die Firewalls, Load-Balancern und andere Netzwerkprofile könnten „kämpfen“ die ersten Verbindungen werden ...

ich bin kein großer Networking Kerl, aber Sie könnten sehen wollen, was ein SA dazu auf serverfault.com auch ...

viel Glück

Answer 5

ich getestet habe zu sagen hat, und mein erstes kalt run (nach dem Neustart des SQL-Dienstes) war in 3 Sekunden (nicht 30 wie deine), alle anderen sind in 0 Sekunden.

Das Codebeispiel die ich verwendet habe eine DLL zu erstellen:

using System; 
using System.Data; 
using System.Net; 
using System.IO; 
using System.Data.SqlClient; 
using System.Data.SqlTypes; 
using Microsoft.SqlServer.Server; 

namespace MySQLCLR 
{ 
    public static class WebRequests 
    { 
     public static void MakeWebRequest(string address, string parameters, int connectTO) 
     { 
      string returnData; 
      HttpWebRequest request = (HttpWebRequest)WebRequest.Create(String.Concat(address.ToString(), "?", parameters.ToString())); 
      request.Timeout = (int)connectTO; 
      request.Method = "GET"; 
      using (WebResponse response = request.GetResponse()) 
      { 
       using (Stream responseStream = response.GetResponseStream()) 
       { 
        using (StreamReader reader = new StreamReader(responseStream)) 
        { 
         returnData = reader.ReadToEnd(); 
         reader.Close(); 
        } 
        responseStream.Close(); 
       } 
       response.Close(); 
      } 
      SqlDataRecord rec = new SqlDataRecord(new SqlMetaData[] { new SqlMetaData("response", SqlDbType.NVarChar, 10000000) }); 
      rec.SetValue(0, returnData); 
      SqlContext.Pipe.Send(rec); 
     } 
    } 
} 

Answer 6

Sieht für mich wie Code Signaturprüfung. Die von MS ausgelieferten System-DLLs sind alle signiert und SQL überprüft die Signaturen zum Zeitpunkt des Ladens. Anscheinend ist die Zertifikatswiderrufsliste abgelaufen und die Zertifikatsüberprüfungs-Engine gibt eine neue Liste aus. Ich habe über dieses Problem vor gebloggt und das Problem wird auch in diesem Technet-Artikel beschrieben: Certificate Revocation and Status Checking.

Die Lösung ist ziemlich obskur und beinhaltet zum Bearbeiten der Registrierung des Schlüssels: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config:

• ChainUrlRetrievalTimeoutMilliseconds Dies ist jede einzelne CRL-Prüfung Aufruf Timeout. Wenn 0 oder nicht vorhanden ist, wird der Standardwert von 15 Sekunden verwendet. Ändern Sie diese Zeitüberschreitung in einen angemessenen Wert wie 200 Millisekunden.
• ChainRevAccumulativeUrlRetrievalTimeoutMilliseconds Dies ist das kumulierte CRL-Abruftimeout. Bei 0 oder nicht vorhanden wird der Standardwert von 20 Sekunden verwendet. Ändern Sie dieses Zeitlimit in einen Wert wie 500 Millisekunden.

Es gibt auch eine spezifische Lösung für Microsoft signed assemblies (dies aus der Biztalk Dokumentation, sondern gilt für alle Montagelast):

manuell laden Microsoft Certificate Sperrlisten

Wenn Sie eine .NET-Anwendung starten, wird das .NET Framework versuchen, die Zertifikatsperrliste (CRL) für alle signierten As herunterzuladen Versammlung. Wenn Ihr System keinen direkten Zugriff auf das Internet hat oder Zugriff auf die Domäne Microsoft.com eingeschränkt ist, kann dies den Start von BizTalk Server verzögern. Um diese Verzögerung beim Start der Anwendung zu vermeiden, können Sie die folgenden Schritte zu manuell herunterladen und installieren Sie den Code Signieren von Zertifikatssperrlisten auf Ihrem System.

1. Laden Sie die neuesten Updates von CRL http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl und http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl.
2. Verschieben Sie die Dateien CodeSignPCA.crl und CodeSignPCA2.crl zum isolierten System .
3. Von einer Eingabeaufforderung geben Sie den folgenden Befehl, um die certutil Dienstprogramm zu verwenden, um die lokalen Zertifikatspeicher mit den CRL in Schritt 1 heruntergeladen zu aktualisieren: certutil -addstore CA c: \ CodeSignPCA.crl

Die CRL-Dateien werden regelmäßig aktualisiert, , so dass Sie eine wiederkehrende Aufgabe des Herunterladens und Installation der CRL-Updates in Betracht ziehen sollten. Um die nächste Aktualisierungszeit anzuzeigen, doppelklicken Sie auf die Datei .crl und zeigen Sie den Wert des Feldes Nächste Aktualisierung an.