Ograniczenia architektury SMP już dawno skłoniły dostawców do poszukiwania innych rozwiązań zwiększania mocy serwerów. IBM opracował technologię MPP (Massive Parallel Processing) polegającą na rozdzieleniu zadań przetwarzania na wiele niezależnych serwerów i późniejszym konsolidowaniu wyników. Ma ona jednak ograniczone zastosowanie, głównie w aplikacjach obliczeniowych i ogromnych bazach danych. Również ze względu na cenę nie ma na świecie zbyt wielu instalacji MPP.

Inną próbą rozwiązania tego samego problemu jest architektura NUMA (Non Uniform Memory Access) opracowana przez firmę Sequent przejętą przed kilkoma laty przez IBM. Podobnie jak MPP, zakłada ona, że duże serwery należy podzielić na mniejsze, a zatem z definicji wydajniejsze podjednostki, dysponujące lokalnymi zasobami pamięci. Architekturę NUMA z biegiem czasu powielili wszyscy liczący się producenci dużych serwerów, jednak jej wpływ na wydajność przeciętnych aplikacji komercyjnych okazał się niewielki. Problem polega na tym, że aby wykorzystać zalety NUMA, trzeba by zmienić architekturę oprogramowania, przepisując tym samym sporą część kodu istniejących aplikacji. Dla uznanych producentów oprogramowania to zbyt kosztowne, mniejsi zaś rzadko tworzą rozwiązania dla najwydajniejszych platform.

Zyskująca obecnie popularność wirtualizacja systemów operacyjnych (oprogramowanie IBM VM, pakiet VMWare i wiele innych) jest kolejnym wcieleniem przetwarzania równoległego. W przeciwieństwie do MPP wirtualizacja polega na uruchomieniu wielu kopii systemu operacyjnego na dużym serwerze. Jej przewaga nad MPP leży w szybkości komunikacji pomiędzy "rozproszonymi" komponentami - przepustowość wewnętrznych ścieżek danych jest wielokrotnie wyższa niż większość połączeń sieciowych. Korzyści wynikają także z uproszczonego zarządzania.

Wydajność serwera zależy od umiejętnego dobrania jego wewnętrznych elementów - zarówno w relacji do siebie nawzajem, jak i w odniesieniu do zastosowań. W pierwszym przypadku chodzi m.in. o zapewnienie dostatecznie dużej pamięci cache, liczby kanałów wejścia-wyjścia w stosunku do wielkości pamięci RAM i mocy procesorów. Co do konkretnych zastosowań, wiadomo np. że wydajność aplikacji bazodanowych jest tym większa, im rzadziej motor bazy musi odwoływać się do pamięci dyskowej. W idealnym przypadku cała baza powinna więc rezydować w pamięci RAM. Z kolei moduły logiczne, a więc aplikacje, wymagają z reguły większej mocy obliczeniowej. Założenia te mają charakter ogólny. W wielu przypadkach aplikacja w formie procedur składowanych rezyduje na tym samym serwerze co baza danych, a to oznacza, że serwer musi mieć zarówno dużo pamięci, jak i dużą moc obliczeniową.

Na wydajność serwera może mieć także wpływ - pozornie nieistotne - fizyczne rozmieszczenie jego wewnętrznych elementów. Często popełnianym błędem jest np. umieszczanie kart PCI blisko siebie. Układ, w którym wiele urządzeń podlega pod ten sam kontroler PCI, niepotrzebnie obniża wydajność. Widać to wyraźnie, gdy na tym samym kontrolerze pracują karty Gigabit Ethernet i Fibre Channel. O ile to możliwe, każde urządzenie serwera powinno mieć własną ścieżkę I/O.

Poznaj swój silnik

Zdecydowana większość problemów z wydajnością systemów wynika z nieprawidłowo zaprojektowanej bazy danych. Jednym ze źródłem problemów związanych z wydajnością baz relacyjnych są nie do końca przemyślane zapytania SQL. Im bardziej skomplikowane zapytanie, tzn. im więcej zawiera warunków, a zwłaszcza formuł obliczeniowych i funkcji wymagających wieloetapowych obliczeń, tym większe ryzyko na jego nieoptymalne wykonanie, np. pół godziny zamiast minuty. Relacyjne bazy danych opra-cowano bowiem z myślą o wydajnej obsłudze transakcji, a nie obliczeń arytmetycznych. Przewidując, że w bazie będzie wykonywanych wiele skomplikowanych operacji, logikę obliczeniową trzeba przenieść poza zapytania SQL, np. do procedur składowanych, które wykonują obliczenia znacznie szybciej.

Często popełnianym błędem jest stosowanie zbyt małej liczby indeksów, które znacznie przyspieszają wyszukiwanie danych. Przy ich braku wyszukiwanie odbywa się sekwencyjnie - rekord po rekordzie. A spadek wydajności widoczny jest już w bazach średniej wielkości, w dużych zaś może to prowadzić do wydłużenia czasu odpowiedzi nawet do kilku godzin. Jest i druga strona medalu. Duża liczba indeksów sprawdza się bowiem przede wszystkim w tych bazach, w których dane rzadko się zmieniają. Aby spełniać swoją funkcję, po każdej zmianie danych źródłowych indeks powinien być aktualizowany, a to zazwyczaj trwa dość długo. W bazach danych, w których równolegle jest wykonywanych wiele operacji odczytu i zapisu, wzrostu wydajności poszukuje się zazwyczaj w rozwiązaniach sprzętowych.