軽量・重量級を問わずサーバーにはさっとデータを書き込んだり読み出す性能が必要だ。
さもないと３人で使っているだけでフリーズするのだから。
そこに求められるのは大容量のRAMだったり高速なストレージだったりするが、これを満足に制御できないCPUでは困る。
例えばサーバーが一人様専用エレベータみたいに動くとすると、すぐ目的の階に行けるのはいいが、乗るまでの待ち時間がとんでもなく長い。これを１０人乗り規模に拡大し、各階の上下ボタンのリクエストを順に拾い上げる様にすると、リスエストあたりのアクセス速度（目的階への最速）は大幅に低下するものの、待ち時間はそれ以上に短縮され、１日に何往復できるか？という大ざっぱな測定をすればパフォーマンスが向上する。
サーバーに要求されるリクエストの大半が 待ち時間＞＞＞処理時間 の傾向にあるので、若干の実処理時間の遅延よりも、目立つ待ち時間を短縮する方が勝るが、リスナーがリクエストをスレッドにばらまくのは、リスナーがすぐ聞き耳を立てないと、応答なしとエラーが返され、再送、再送・・・となりネットワークの負荷が一気に膨らんでしまうからだ。
もう一つは消費電力と発熱。前世代の様なホストサーバーなら、いくつものユニットの集合体であったがメーカーが一式で提供していたので、消費電力も検討が付きやすかった。今は泥縄式に（メーカー不問の）サーバーを増やせるので、新CPUの登場でユニットあたりの消費電力が１割増えただけで想定外の事態に発展する。
手早く暗号化や復調ができること。ここみたいに一人で記事を書いている分にはhttpsのプロトコルが多少重くても、１タスク待っていればいいだけだ。しかし一般に多数のユーザがhttpsなページにアクセスした途端にヘナヘナになるようなCPUであっては困る。万が一、サーバーからアカウント情報が漏えいした場合には一斉にユーザにパスワードの更新を求めることになるが、一斉にユーザがhttpsなパスワードの更新の画面にアクセスするとやはりヘナヘナになって落ちるはずだ。セキュリティが破られた後の後始末でも使うのだから要注意。
文字の変換、文字列の処理が容易なこと。httpではいろんな文字コードを使用するので、相互に文字コードの変換が必要だ。また記事のhttpページはいくつものテキストを組み合わせて作られている。だから文字列なんて長さ未定の可変長データは苦手なCPUでは困る。もちろん、そんなデータベースなら、なおさらお断りだ。