Immer wieder werden im Projekt heftige Dikussion um die CPU Bestückung des BLS geführt. Bei einem Blick in den Taskmanager zeigt dieser auf dem BLS oft nur eine Auslastung unter 50% an, was zu der Annahme verleitet, dass keine weiteren CPUs für den BLS mehr notwendig sind. Allerdings ist die Aussage des Taskmanager völlig unbrauchbar, das nicht die aktuelle Auslastung der CPU, sondern die Warteschlange vor der CPU den entscheidenen Messwert darstellt.

Speziell bei DSM werden zig asynchrone Prozesse gestartet, die bei einer geringen Anzahl von CPUs seriell abgearbeitet werden müssen. Dabei belegt der erste Prozess die CPU ein bisschen, wird auf Hold gesetzt, weil der zweite Prozess mit höhere Priorität Resourcen zugewiesen bekommt, dann belegt der zweite Prozess ein bisschen, dann kommt der dritte, und so weiter. Bis der erste Prozess abgearbeitet ist, kann also einige Zeit vergehen. Das Problem wirkt sich immer stärker aus, um so mehr Clients, Schnittstellen und Konsolen in die DSM Umgebung eingebunden sind. Die CPU ist also mehr mit dem Management der Prozesse beschäftigt, als mit der wirklichen Abarbeitung der Aufgaben.

Aufgrund der unterscheidlichkeit der Randparameter (Anzahl Client, Policydesign, Anzahl Pakete, Anzahl Schnittstellen und Consolen, etc.), gibt es leider keine Formel zur Berechnung der "korrekten" Anzahl der CPUs. Der Grundsatz "Viel hilft viel" ist letztlich der einzige realistische Ansatz, der in der Praxis angewendet werden kann.

Somit ist es immer empfehlenswert, den BLS mit einem möglichen (wirtschaftlichen/technischen) Maximum an CPU auszustatten. Auch wenn der BLS virtualisiert ist und keine dedizierten CPUs zugewiesen bekommt, lohnt es sich die Last des BLS auf möglichst viele Shared CPUs zu verteilen. Die Auswirkung auf die Performance ist beim Clientsync anhand der Logfiles sehr gut messbar und in der DSMC ist speziell bei einem Update der CPUs ein merklich fühlbarer Performance Gewinn zu vermerken.