Pomiar należy rozpocząć przy normalnej eksploatacji i optymalnej konfiguracji sieci. Nie warto czekać do wystąpienia problemów. Gdy już się pojawią, badanie sieci SAN jest trudne.

Pomiary wykonywane jeszcze przed kosztownymi pracami optymalizacyjnymi przynoszą bardzo dobre efekty. Umożliwiają wychwycenie miejsc, gdzie nieefektywnie wykorzystuje się pasmo oraz odnalezienie złego przepływu danych w konfiguracji wielościeżkowej. Wykazują problemy z równoważeniem obciążenia interfejsów, niedoskonałości w warstwie fizycznej oraz kłopoty z konfiguracją (zoning, rozmiar IO request, kolejki).

Znaleźć istotne parametry

Należy mierzyć te parametry, które rzeczywiście mają wpływ na pracę aplikacji. W wielu firmach polega się na wielkościach, które mierzyć najprościej - na przykład, ilość operacji I/O na sekundę. Niestety, ten parametr nie zawsze oddaje wydajność pracy aplikacji. Znacznie lepiej mierzyć zestaw trzech wartości, minimalnej, maksymalnej i średniej, dla następujących parametrów określonych dla każdego adaptera HBA, portu storage oraz numeru jednostki logicznej LUN:

czas ECT (exchange completion time)

czas od wysłania komendy odczytu do pierwszych danych

długość kolejki (albo parametr pending exchanges)

rozmiar danych odczytywanych, zapisywanych i innych.

Ustalić, co wynik mówi o pracy systemów

Należy uwzględnić, jak pomiary danej wielkości oddają pracę systemu i aplikacji. Częstym błędem jest poleganie na czasie odpowiedzi serwera (mierzonym z systemu operacyjnego lub aplikacji) do określenia stanu działania całej infrastruktury. Przyczyną problemów może być przecież chwilowe, bardzo silne obciążenie CPU, niekoniecznie zaś długi czas transakcji I/O.

Gdy pojawia się spowolnienie pracy, do skutku dochodzi mniej transakcji. Jeśli problem dotyczy jednego z wielu zasobów serwera (na przykład, pojedynczego LUN), średni czas odpowiedzi może wyglądać całkiem poprawnie - a aplikacja nadal działa źle. Znalezienie źródła problemu może być trudniejsze niż się na pozór wydaje.

Mierzyć kompletną ścieżkę danych

Ponieważ czas odpowiedzi aplikacji jest podawany na serwerze przez sam serwer, jest to jedynie zgrubny miernik wydajności infrastruktury. Zamiast pomiaru czasu odpowiedzi aplikacji, warto zainteresować się raczej zmianami opóźnień na ścieżce danych. W ten sposób prędzej można znaleźć przyczynę problemów.