🚀 go-pugleaf

wloochacz pisze:


Na początek przyznam się, że nie znam Codesite'a.

> I to wszystko prawda, ale... CodeSite równie dobrze może działać na
> warstwie transportowej TCP/IP a messages są używane domyślnie.

SI oferuje transporty:
1.binary files - pliki SIL (używam)
2.Named Pipes (używam)
3.TCP (nie używam)
4.Text Files (nie używam)
5.Memory (używam)

Może dziwić, dlaczego nie używam TCP. Otóż konsolę jeśli odpalam to 
praktycznie zawsze na serwerze. Użycie transportu TCP może spowalniać 
wykonywanie wątków, zwłaszcza gdy nie jest uruchomiona konsola.


Dla mnie ogromną zaletą SI jest bardzo dobry system filtrowania 
wyświetlanych w konsoli komunikatów. Dwoma kliknięciami myszy tworzę 
filtr ograniczający widok do komunikatów należących do okreslonego 
wątku. To wszystko pozwala zrozumieć działanie aplikacji wielowątkowych 
i wychwycić słabe punkty alogorytmu.

Konsola dostępna jest w dwóch wersjach:
-Redistributable (bezpłatna)
-Professional

Pierwsza z nich nie posiada mechanizmu korzystania z predefiniowanych 
filtrów. Dostępny jest tylko jeden - bieżący.


> Każdy logger może działać z różnymi Destinations - a więc równocześnie
> może logować np. do pliku, serwera TCP/IP czy LiveViewer'a.

Jeśli chodzi o różne przekroje logowania, to myślę że docelowo przydatne 
jest:
-posiadanie pełnych logów (level DEBUG) w celu analizowania problemów 
technicznych
-oddzielny log zbierający wybrane komunikaty (level ERROR, ew. dodatkowo 
WARNING). Plik ten może być monitorownay przez inne systemy np. Nagios

Przyznaję szczerze, że na razie ograniczam się do pierwszego przypadku. 
Standardowo ustawiam wielkość pojedynczego pliku SIL na 30 MB, liczba 
plików 30, rotacja codziennie.

Drugi "przekrój" logów to ich źródło. W SI realizuje się to za pomocą 
sesji. Robię to tak, że w każdej ważniejszej klasie (Controller, 
Boundary) wewnątrz bloku initialization tworzę nowy obiekt Session 
widoczny w implementacji unitu.

[OFF topic] Wydaje mi się, że lepiej nie używać sekcji Initialization. 
Może to wnosić niepotrzebne zamieszanie. Zdaję sobie sprawę, że ten 
mechanizm jest wykorzystywany do rejestracji klas w fabrykach, mam 
jednak mieszane uczucia.

Uważam, że nie jest dobrym pomysłem umieszczanie komunikatów z różnych 
sesji w oddzielnych plikach, lepiej zostawić je w jednym. Wtedy łatwiej 
jest analizować zależności czasowe pomiędzy komunikatami.

SI zapewnia logowanie nie tylko komunikatów tekstowych, ale również 
obiektów (np. TStringlist),typów prostych,, grafiki, pamięci, strumieni, 
stron HTML, screenshotów, datasetów itd.
Innym mechanizmem, który jest konkurencją dla Microsoftowego Performance 
Management jest wsparcie dla liczników i watchy. Możliwe jest logowanie 
wartości np. typu String, Integer. Aktualna wartość liczników jest 
prezentowana w dedykowanym oknie. Na podstawie zmian ww wartości możliwe 
jest utworzenie wykresów zmiany w czasie.

Jesli chodzi o architekturę logowania, dostępny jest jeszcze moduł SI 
Router umożliwiający centralne zapisywanie logów na dedykowanej maszynie.

Dla niektórych może mieć też znaczenie, że SI jest dostępny w formie 
bibliotek do Javy, C# (wspiera LINQ to SQL).


-- 
pozdrawiam
Piotr
XLR250&bmw_f650_dakar