2009-07-17 11 views
18

Próbuję zminimalizować kary za wydajność związane z komunikowaniem się między AppDomains na tym samym komputerze. W moim przykładzie zabawkowym klasa A jest ładowana w AppDomain 1. Tworzy AppDomain 2 i ładuje tam instancję klasy 2 (Class 2 dziedziczy z MarshalByRef), odzyskując proxy. Następnie klasa 1 wielokrotnie wywołuje metodę na serwerze proxy, która nie zwraca żadnych wartości.Jaka jest minimalna kara za wydajność komunikacji Cross AppDomain?

uzyskać następujące wyniki:

  1. Brak AppDomains, obie klasy są ładowane w tym samym AppDomain i pierwsze zaproszenia repetedly metodę na drugi (metoda ma parametry): metody połączenia/s
  2. Dwa AppDomain jak opisano powyżej, sposób nie ma parametrów lub „krwawienie” parametry ciągu: 340.000 metody połączeń/sek
  3. dwa AppDomains jak opisano powyżej, jeden serializacji parametr (tablica dwóch łańcucha s): 64,000 wywołania metod/s

Chociaż rozumiem karę wydajności pomiędzy 2 i 3 (serializacji), ja naprawdę nie rozumiem, dlaczego jestem 100 razy wolniejsze od przypadku do przypadku 1 2 . Według mojego zrozumienia, po utworzeniu proxy wszystkie późniejsze wywołania metod muszą być naprawdę szybkie, ponieważ żadne dane nie są kierowane z jednego AppDomain do drugiego. Czy ktokolwiek wie, dlaczego komunikacja w AppDomains jest tak powolna? czy robię coś źle?

PS1. Jedyną wskazówką, którą mam na ten temat, jest here: "Koszt przekroczenia granicy AppDomain jest kłopotliwy.". Zgaduję, że odnosi się do serializacji ...

PS2. Nie liczę czasu utworzenia AppDomain lub Proxy (moje testy porównawcze rozpoczynają się od pierwszego wywołania metody)

PS3. Korzystam z .NET 3.5 na maszynie WinXP SP3. Próbowałem także .NET 4.0 Beta 1 bez znaczących różnic.

Odpowiedz

11

Jeśli policzysz linie IL zaangażowane w każdym scenariuszu, zobaczysz, że CLR wykonuje ponad 100 razy pracę podczas zdalnego uruchamiania. Bezpośrednie wywołanie jest tylko kilkoma opkodami, ale przy zdalnym uruchamianiu występuje wiele klas, rzeczywiste/przezroczyste serwery proxy, kontrole bezpieczeństwa, serializacja, yadda yadda yadda. Będziesz musiał zająć się tym poprzez projekt - nie ma magicznej kuli, aby ulepszyć perf poprzez wdrożenie.

+1

+1 Całkowicie się z tobą zgadzam. Proste bezpośrednie wywołanie metody jest niezwykle proste. Wywołanie metody poprzez ** zdalne ** jest znacznie większe. Narzut jest znacznie większy. Jedynym realnym rozwiązaniem jest dobry projekt aplikacji, który nie zależy od szybkości komunikacji Cross AppDomain. – jpbochi

1

Czy istnieje sposób, w jaki można wywołać pojedynczą metodę pomocniczą, która pobiera parametry określające ile razy trzeba wywołać żądaną metodę? Wydajność połączeń Cross-AppDomain różni się znacznie w zależności od implementacji. Uważam, że może być znacznie lepszy w CLR 4.0, ale nie jestem w pełni zorientowany w szczegółach.

Ogólnie rzecz biorąc, chcesz uniknąć narzutu poprzez "grupowanie" wywołań za pomocą metody pomocniczej.

+0

Nie widzę, jak to mi pomoże. Metoda mojej klasy A robi dokładnie to: ciągłe wywoływanie object.MyMethod().Jeśli koszt połączenia w proxy jest rzeczywiście 100 razy większy niż koszt wywołania tego samego obiektu AppDomain, wpływ na mój projekt będzie ogromny. – Yiannis

+3

Wywołanie object.MyHelperMethod, które wywołuje object.MyMethod wielokrotnie w innym AppDomain. Jeśli potrzebujesz wydajności i założyliście/wymagaliście szybkiego wywoływania aplikacji typu AppDomain, to tak, może to mieć duży wpływ na Twój projekt. –

+0

Ohh, widzę ...! :-) OK, to oczywiście przyspieszy sprawę. Ale ten przykład to tylko zabawka, mój prawdziwy program nie wywoła tej samej funkcji 20 mil na sekundę ..! Będę musiał wykonywać różne połączenia między domenami AppDomain, które ogólnie muszą być szybkie. Thnanks mimo to! – Yiannis

0

Widziałem takie same wyniki. Nie potrafię wyjaśnić, dlaczego jest tak wolniej, z tym, że jest szybszy niż uruchomienie dwóch różnych procesów i komunikowanie się ze sobą. W moim projekcie stanąłem przed podobnym dylematem. Na koniec zmodyfikowałem swój projekt, aby stworzyć niezależne domeny aplikacji; domena aplikacji była w stanie wykonać swoją pracę bez potrzeby komunikowania się z inną domeną aplikacji podczas wykonywania ... Po zakończeniu raportowałby tylko dane.