Dropbox im Zusammenspiel mit TrueCrypt. Klappt wunderbar. Vor allem, da nach dem Initialisieren des Container nur mehr die Änderungen abgeglichen werden und nicht stets die gesamte Container-Datei übertragen werden muss.

Hallo,

hatte vor längerer Zeit genau das gleiche Problem wie dN!3L. Habe es so gelöst, dass ich die Proxy-Objekte nicht direkt in einer Liste bzw. abgeleiteten/erweiterten Liste verwalte, sondern diese in eine Wrapper-Klasse ausgelagert habe. In dieser wurden zusätzlich noch weitere Informationen wie Hostname, Port und IP gespeichert, um z.B. bei einer Remoting-Exception nachträglich noch auf diese Informationen zugreifen und den Schuldigen rasch identifizieren zu können.

Vereinfacht würde das etwa so aussehen:

namespace RemoteTestingLibrary.Host
{
    public class TestHostInformation
    {
        private string _hostname;
        private int _port;
        private TestHost _host;  // Remote-Proxy, implementiert IObserver

        public TestHostInformation(TestHost host)
        {
            _hostname = ((IObserver)host).Hostname;
            _port = ((IObserver)host).Port;
            _host = host;
        }
    }
}

Die Server-Instanz verwaltet dann eine List mit den Objekten dieser Klasse:

namespace RemoteTestingLibrary.Controller
{
    [Serializable]
    public class TestHostController : MarshalByRefObject, IControllable
    {
        private static List<TestHostInformation> testHosts;

        public void Attach(IObserver observer)
        {
            TestHostInformation info = new TestHostInformation((TestHost)observer);
            testHosts.Add(info);
            OnHostAttached(new HostEventArgs(info.Hostname, info.Port, info.HostType));
        }

        public void Detach(IObserver observer)
        {
            TestHostInformation info = new TestHostInformation((TestHost)observer);
            testHosts.Remove(info);
            OnHostDetached(new HostEventArgs(info.Hostname, info.Port, info.HostType));
        }
    }
}

Auf diese Weise können auch noch weitere relevante Felder zwischengespeichert werden, auf die der Server stets Zugriff haben sollte, ohne einen RPC auszulösen. Vor allem für das Debugging sehr hilfreich.

Liebe Grüße.

den redgate profiler haben wir auch eine weile verwendet.

die tatsächlich angezeigten zeiten der methoden sind beim messen aber um ein vielfaches länger als in der tatsächlichen ausführung - allerdings stimmen sie ziemlich gut, wenn man sie im verhältnis zu anderen betrachtet. dadurch kann man relevanten stellen mit schwacher performance trotzdem gut identifizieren.

Grundsätzlich ja, in vielen Fällen leider nur sehr eingeschränkt, da es auch stark darauf ankommt, was für Code dem Profiler unterworfen wird. Die auftretenden Auswirkungen auf Laufzeit sind je nach Umfang der aufgezeichneten Daten (bei vielen Profilern u.a. CPU-Zeit, Memory Consumption der CLR, Ausführungszeit der Methoden, etc) und der Häufigkeit der Messung unterschiedlich stark, weswegen viele Profiler auch unterschiedliche Messmodi bieten.

Ich habe eines unserer Projekte (Winforms-Anwendung mit vielen Custom Controls, ADO.NET und etwas Remoting) unter mehreren Profiling-Lösungen getestet, wobei die meisten Ergebnisse der am Markt erhältlichen Profiler je nach Profiling Modus z.T. wirklich massive Auswirkungen auf die Laufzeit der Anwendungen haben und kaum oder gar keine Aussagen über die eigentliche Performance zuässig sind.

Speziell bei GUI-Code weisen so gut wie alle Profiler große Schwächen auf, wobei ANTS von RedGate hier mit Abstand das Schlusslicht bildet. So verlängert sich bei unserem Projekt z.B. rein die Initialisierungsdauer der Oberfläche (ca. 6 Sekunden ohne Profiler) bei Red Gate auf einem P4-Rechner mit 3Ghz mit 2 Gig Ram um den Faktor 17 (sic!).

Speziell der Profiler von Red Gate liefert in unserem Fall eigentlich nur mehr lachhafte Werte. Ein großer Nachteil, der so gut wie bei allen Profilern zu tragen kommt: es kann nicht bestimmt werden, welche Daten genau gesammelt werden sollen (es gibt wenn dann nur vorgefertigte Profile zur Auswahl), womit sich die Auswirkungen womöglich auf ein Mindestmaß reduzieren ließen. Insofern ist es dadurch auch nicht möglich, die Produkte untereinander einem direkten Vergleich zu unterziehen, da jeweils unterschiedliche Metriken gemessen werden.

Prinzipiell stimme ich 0815Coder zu, dass sich Profiling wohl für relative Vergleiche von Performancedaten nutzen lässt (etwa Vergleich zwischen unterschiedlichen Builds), imho sollten die dabei erzielten Ergebnisse jedoch äußerst kritischen hinsichtlich ihrer Aussagekraft beurteilt werden.

Der Profiler mit dem geringsten Einfluss auf die Laufzeit unserer Anwendung misst selber nur die Ausführungszeit der einzelnen Methoden, was vielen wohl reichen dürfte. Mir hätte es dies, jedoch bin ich dazu übergegangen, die Ausführungszeiten der Methoden selber mittels AOP-Techniken zu messen und dies mit dem AOP-Framework PostSharp zu implementieren. Diese Vorgehensweise hat in unserem Fall folgende Vorteile:
*Anwendung des Aspekts (OnMethodBoundaryAspect) auf beliebige Methoden über Attributierung (auch auf Klassen oder gar Assembly-Ebene, wodurch der erforderliche, manuelle Eingriff auch bei großen Projekten minimiert wird). PostSharp bietet dafür recht mächtige Mittel, so kann z.B. der Aspekt zur Performancemessung per Regex auf beliebige Methoden oder Klassen eines Assemblies angewendet werden.

Um beispielsweise alle Methoden des Logic Layer zu mesen, würde folgendes Assembly-Attribut reichen:

[Assembly: PerformanceAspect(AttributeTargetAssemblies:="LogicLayerAssembly")]

*Es kann innerhalb des Aspekts bestimmt werden, was mit den aufgezeichneten Daten passiert. Ich mache es so, dass alle Werte mitsamt den Methodeninformationen (die PostSharp als Argument mitliefert) in einer Klasse geskapselt werden. Der Aspektcode jeder instrumentierten Methode erstellt vor dem Betreten der Methode ein Objekte dieser Klasse, speichert die Ausführungszeit nach dem Verlassen der Methode und legt das Objekt temporär in einer globalen Liste ab. Diese Liste kann nach dem Messvorgang für die Analyse beliebig exportiert werden. Bei uns geschieht das entweder in Form einer CSV-Datei oder in einer Datenbanktabelle, um die Daten per Excel/SQL filtern und auswerten zu können.

*Die Aufzeichnung kann zur Laufzeit aktiviert bzw. deaktiviert werden.

*In der Aspektklasse kann ein Grenzwert eingebaut werden, um alle Zeiten unter diesem Wert zu ignorieren, was das Volumen der Messdaten reduziert, die Konzentration auf die Heavy Hitters erlaubt und die Auswertung der Daten letztendlich vereinfacht.

Auf diese Weise lässt sich einerseits der Overhead durch den Messvorgang selbst auf ein Minimum reduzieren (wo? wann? wieviel?) und andererseits die dabei aufgezeichneten Daten in beliebiger Form weiterverarbeiten.

Empfehle daher, für die Messung der Ausführungszeit von Methoden AOP-Techniken zumindest in Betracht zu ziehen. Speziell PostSharp bietet da geniale Möglichkeiten. 🙂