ASP.NET ReportViewer Google Chrome CPU-Auslastung

Question

Wir haben ein interessantes Problem zwischen ASP.NET 3.5 und ReportViewer mit Google Chrome gefunden. Unsere Seiten funktionieren so lange, bis ein ReportViewer-Steuerelement einen Bericht anzeigt.

Google Chrome dann frisst 50% der CPU nichts tut es scheint.

Ich habe das ReportViewer-Steuerelement in ein leeres Web Forms-Projekt extrahiert, um zu bestätigen, dass es dieses Steuerelement ist, und kein Rogue-Bit meines Codes.

Ich verwende ReportViewer im lokalen Modus (RDLC-Datei), also nehme ich an, dass es die Version 2005 ist?

Wer hat das schon mal gesehen und eine Lösung?

Phil

Edit: Google Chrome 3.0.195.33 auf Vista Business x64

Edit 2: hinzugefügt Prämie um Hilfe dieses

Answer 1

Die Lösung ist tatsächlich einige der ReportViewer JavaScript verursacht eine Endlosschleife in Chrome, ich posten den Quellcode, wie dieses Problem gelöst werden, indem Sie eine benutzerdefinierte Version des ReportViewer steuern und das kaputte JavaScript (ich habe habe den Link zur Lösung verloren, aber ich habe das nicht geschrieben, einfach genutzt :))

Ich kann bestätigen, dass wir jetzt auf den neuesten ReportViewer in Visual Studio 2010 aktualisiert haben, das Chrome-CPU-Problem existiert nicht mehr und Diese Arbeit ist nicht erforderlich.

public class MyReportViewer : Microsoft.Reporting.WebForms.ReportViewer 
{ 
    protected override void Render(HtmlTextWriter writer) 
    { 
     using (StringWriter sw = new StringWriter()) 
     { 
      HtmlTextWriter tmpWriter = new HtmlTextWriter(sw); 
      base.Render(tmpWriter); 
      string val = sw.ToString(); 
      val = val.Replace(@"!= 'javascript:\'\''", @"!= 'javascript:\'\'' && false"); 
      writer.Write(val); 
     } 
    } 
} 

Answer 2

Ich hatte dieses Problem zu lösen und es trieb mich absolut verrückt!

Zunächst speichern Sie die generierte Datei - das ist, wenn Sie können. Manchmal gefriert es. Speichern und überprüfen Sie die Größe des Berichts, der generiert wird. Mein Problem wurde in Dateien mit mehr als 16 MB ausgelöst und verlangsamt den Browser und das Netzwerk.

Tun Sie sich einen Gefallen, werfen Sie einen Blick auf den HTML-Code, indem Sie die Quelle anzeigen, die im Webformular generiert wird. Überprüfen Sie, ob das Styling explizit inline innerhalb des generierten Dokuments geschrieben wurde und nicht aus einer Datei referenziert wurde.

Versuchen Sie, das Styling aus dem Bericht zu entfernen und sehen Sie, ob das hilft.

Answer 3

Es gibt einen Thread in den Google Chrome-Foren, in dem darüber gesprochen wird. Ich weiß nicht, ob es möglich ist, dass Sie den Bericht auf dem Server statt lokal ausführen, was das Problem zu beheben scheint. Hier ist der Thread: ReportViewer rendering maxes out thread CPU usage

Answer 4

Während Chrome ist ein netter Browser und entwickelt sich ziemlich schnell, ich fürchte, es gibt für jetzt keine andere Lösung als einen anderen Browser verwenden. Ich würde denken, dass Google an diesem Problem irgendwann arbeiten wird, aber für jetzt ist es nicht behoben.

Ich denke, sie würden versuchen, andere Probleme zu beheben. Ich sah andere Seiten auf seltsame Weise mit Chrome und nicht mit IE gerendert werden.

Answer 5

Wenn Sie den Report Manager wie mich (Version 2005) verwenden, können Sie nicht viel über das ReportViewer-Steuerelement tun. (Gibt es das?) Es gibt jedoch eine Alternative:

Die Lösung von Phil deaktiviert effektiv den Code, der vom Onload-Ereignis eines Iframes ausgeführt wird.In SSRS 2005 ist dies ein iframe mit id 'ctl140TouchSession0':

<iframe name="ctl140TouchSession0" id="ctl140TouchSession0" onload="if (frames['ctl140TouchSession0'].location != 'javascript:\'\'') frames['ctl140TouchSession0'].location.replace('javascript:\'\'');" src="javascript:''" style="position:absolute;width:0;height:0;border-width:0;visibility:hidden;"> 

Sie den problematischen Code in dem Onload-Ereignisse sehen können - der deaktiviert Render Code die if-Anweisung von "& & false" an die Bedingung hinzugefügt wird.

Das folgende Javascript erreicht die gleiche Sache durch Leeren der Onload, nachdem die Seite geladen ist, die Schleife zu stoppen.

(Fügen Sie diese am unteren Rand des [MSSQL Berichtsservices Ordner] \ Report \ js \ ReportingServices.js)

// CUSTOMIZATIONS 
addLoadEvent(customize); 

//some browser-independent onload-adder I pulled from somewhere 
function addLoadEvent(fn) 
{ 
    if (window.addEventListener) 
     window.addEventListener('load', fn, false); 
    else if (window.attachEvent) 
     window.attachEvent('onload', fn); 
} 

function customize() 
{ 
    //the actual fix. 
    //check first, we may be in a page without a reportviewer 
    if(document.getElementById('ctl140TouchSession0')) 
     document.getElementById('ctl140TouchSession0').onload = ""; 
} 

Hinweis: Ich bin nicht sicher, was das Onload-Ereignis tatsächlich tut, und wenn es so zu entfernen tötet einige andere Funktionen. Es sollte eine Möglichkeit geben, das Onload auf die gleiche Weise zu ändern, wie Phils Lösung oder ein browserabhängiger Fix, aber das macht den Trick und ich habe noch keine Probleme in IE gefunden.

Answer 6

Das hat für mich funktioniert, es ist nicht so, dass ich es trotzdem empfehlen würde. Ich bemerkte, dass mein WebKitInspector den Browser einfrieren ließ.

var iframes = document.getElementsByTagName("IFRAME"); 

for (var i = 0, ln = iframes.length; i < ln; i++) { 

    iframes[0].parentNode.removeChild(iframes[0]); 
} 

Answer 7

Wenn wir die doc Art von ändern:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"> 

zu:

!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 

es auf Chrom funktioniert aber nicht mehr funktioniert auf IE.