🚀 go-pugleaf

j_marek napisał(a):
> Tomasz Muszyński <thom_ek@op.pl_nospam> napisał(a):
>> No to ja wiem... ale trochę to głupie jak program praktycznie nic nie
>> robi a zajmuje mi tyle ramu.
>
> [...]
> 
> Natomiast czytałem opinie, że .NET właśnie bardzo dobrze się nadaje na 
> aplikacje serwerowe. GC nie powoduje fragmentacji pamięci w długo 
> działających procesach, JIT nie ma znaczenie. Być może po prostu Twoja 
> aplikacja ma jakieś problem z zarządzaniem pamięcią. GS nie załatwia 
> wszystkie automatycznie.

No właśnie teraz przerobiłem to na wersję serwerową i jest super.
Zabawa z GC nic nie zmieni, bo zajętość pamieci jest prawie stała od 
odpalenia do zakończenia COM'a.

> Jeśli to jest problem to być może powienneś zdecydować się umieszczenie 
> kodu w jednym procesie zamiast odpalać ich tak wiele. A każdy z osobną 
> zarządzaną stertą, narzutem związanym z odpaleniem procesu.

Sposób uruchamiania został mi narzucony odgórnie: COM lub DLL. 
Oczywiście jeśli .Net to i COM... który prawie nic nie robi, ale jest 
COMem i wykorzystuję remoting, więc to może trochę zżera. Trochę ramu 
zajmuje też ten exec co wywołuje mojego COMa - dokładniej mówiąc, to 
15mb ma exec, a 10mb ma .Net :) Przyznaję się, że to nie te 20mb o 
których pisałem, ale stopień skomplikowania tego execa do COM'a to jak 
Word do Notepad'a :) Zajętość pamięci podaje mi Task Manager.

Teraz jednak zrobiłem taką optymalizację, że większość kodu przeniosłem 
do osobnego serwisu, a tam już działa to na wątkach. Wykopałem także 
remoting łączący się do serwisu na rzecz socketów. Dzięki tym operacjom 
COM się tak uprościł, że mogę go przepisać do zwykłej DLL'ki napisanej w 
C++. Sama aplikacja serwerowa (do której się ten COM/DLL podłącza) jest 
już bardzo rozbudowana i jak narazie zachowuje się idealnie. Teraz muszę 
jeszcze wykonać testy obciążeniowe...

Ale co do samego .Neta... ewentualne jego minusy nie zmieniają jednak 
faktu, że 95% napisanego przeze mnie softu to .Net i na długi czas tak 
pozostanie :)

tm