マイクロカーネル
しかし、サーバで障害が発生することでシステム状態の一部が失われることがあるため、アプリケーション側もサーバ障害に対応する必要がある。例えば、TCP/IP接続を担うサーバがあるとする。このサーバを再起動すると、アプリケーションから見てコネクションが失われることになるが、これは通常のネットワークでも起き得る障害である。しかしアプリケーションが障害発生を予期していないサービスの場合、アプリケーションのコードを修正する必要がある。QNXではサーバの再起動への対応として QNX High Availability Toolkit が提供されている。
全サーバを再起動可能にするため、トランザクションやレプリケーションやチェックポインティング(英語版)といったデータベース的技法を取り入れているマイクロカーネルもある。例えば ChorusOS があり、電気通信業界の高信頼アプリケーション用にそのような機能を備えている。
L4のIPC性能は様々なアーキテクチャ上で最速を誇った。
そういった結果により、第一世代のマイクロカーネルの性能の低さは第二世代のL4などのマイクロカーネルには当てはまらないことを示したが、マイクロカーネルをベースにしたシステムが高性能を発揮できることを証明したわけではなかった。それでもモノリシックなLinuxサーバをL4上に移植したものは、通常のLinuxに対して数パーセントのオーバーヘッドを示しただけだった。しかし、単一サーバシステムはマイクロカーネルの利点を生かしているとは言い難く、OSの機能を複数のサーバに分離したときの性能が重要だとされた。
複数サーバの商用システムはいくつか存在しており、例えばリアルタイムオペレーティングシステムのQNXやIntegrity(英語版)がある。そういったシステムとモノリシックなシステムとの包括的性能比較は公表されたことがない。さらに言えばそれら商用システムでは性能が最重要課題ではないようで、割り込み応答時間の保証や頑健性のための単純さが強調されている。複数サーバの高性能OSを構築する試みとしてIBMの Sawmill Linux というプロジェクトがあった。しかし、このプロジェクトは完了することなく中止された。
同じころ、ギガビット・イーサネットのような高速デバイスのデバイスドライバをユーザーレベルで実装したものが、カーネル内のデバイスドライバと同等の性能を発揮することが示されている。これは複数サーバの高性能システムが構築可能であることを示唆している。