Pocket Groupware Server：パフォーマンス評価

インターネットは1995-96年にロシアに来ました。 平均的なコンピューターは、AMD 486DX150または4〜8 MBのRAMと100〜400 MBのHDDを搭載したIntel Pentium100でした。 ちょうどそのとき、Windows 95が登場しました。指定された値にハードウェアをアップグレードする必要があったのは新しいOSでした。 94年目のコンピューター486 SX25または2〜4 MbのWin95を搭載したDX66の典型的な例では、ほとんど放り投げられませんでした。 当時のプロバイダーのインターネットサーバーとルーターには、まったく同じマシンがありました。 Linuxはそれでも2 MB（GUIなし）で非常に快適で、サイトはほとんど静的で、メールスパムはまだありませんでした。 せいぜい、1,000人に1人がインターネットにアクセスできました。平均的なロシアの地域センターでは数百人で、全員が個別のプロバイダーのメールサーバーとWebサーバーを使用していました。 つまり、指定された構成の1台のサーバーは、現代の標準では重要ではありませんが、かなり大規模な企業のインターネットユーザーと同じくらい多くの人々が対応していました。 そして対処...



現在、同等のパワーのコンピューターがありますか（パワーという言葉がまだそのようなハードウェアに当てはまる場合）、そしてそれらはどのように使用されていますか？ あります。 いいえ、これらはルーターではなく、特にスマートフォンではありません-家庭用ルーターと最も単純な電話だけを考慮しても、両方とも著しく生産的です。 ルーターは100 Mbpsを簡単にポンピングし、電話はビデオを簡単に回転させます。電話には数百メガバイトのメモリがあります。96mではそのようなものはありませんでした。 Pentium100に匹敵する弱いプロセッサ、つまり約100MHzまたは最大200 DMIPSを探す必要があります...







比較の最も近い候補は、ARM Cortex-M3または-M4マイクロコントローラーです。 最初の周波数は100MHz未満で、2番目の周波数はわずかに高く、宣言されたパフォーマンスは125-210 DMIPSです（2.19 CoreMark / MHz-1.25 DMIPS / MHz-Pentiumの96mと同様）。 コントローラーの内蔵SRAMは約100Kbのみですが、メガバイトの外部SDRAMをコントローラーに接続できます。これは最初のPentiumと同じ周波数で動作します。 合計すると、当時のマザーボードとほぼ同等の値が得られますが、ボード全体のサイズはPentiumソケットよりも小さくなり、消費電力は当時の（わずか10 W！）Pentiumよりも1桁小さくなります。



どのように、何を比較し、最も重要なのはなぜですか。 非定型ネットワークタスクのCortex-M3のパフォーマンスを測定します。 多くのCortex-M3にはイーサネットコントローラーがあり、TIのバージョンにはPHYが組み込まれています（つまり、外部チップを必要とせず、MagJack RJ45に直接接続します）が、これは産業オートメーションに使用する必要があると考えられています-ネットワークまたは自宅での制御/監視チームの駆動-ユーティリティの消費、「スマートホーム」の管理などのためのネットワークメーター。 重要なタスクですが、完全に「別のオペラから」。 しかし、予想されるパフォーマンスによれば、これは過去に都市全体を「提供」したサーバーに対応するため、この従来のニッチに限定されるべきではなく、サーバータスクに対するコントローラーの適用性を評価することは理にかなっていますか？ インターネット上ではなく、ローカルネットワーク用。 宇宙船が宇宙の広がりを耕し、企業のIT部門が外部のクラウドに内部タスクを外部委託するとき、通常のオフィスPCよりも数百または数千倍遅いマシンに実際のネットワークサービスを配置するタスクは無意味に思えるかもしれません。 しかし一方で、コントローラーが（突然）タスクに対処する場合、この特定のタスクを解決するときにハードウェアが「軍拡競争」を無意味にしないのでしょうか？ そして、これは私たちのエンジニアリング作業が最終分析に含まれるものではありません。 生産コストを削減することで？ そのため、（1）同じお金でより多く行われるか、（2）より少ないお金でより多くの作業が行われます。 2番目のオプションで、機能の制限を確認します。



次に、テストタスクの選択について説明します。 操作の量が時間的に一定であるITタスクが1つあります。これは、それらが機器の能力ではなく、技術プロセスの最も遅い参加者である人間の生産性によって制限されるためです。 さらに、このプロセスは最も人間的である意思決定プロセスであるため、残念ながら（または幸いなことに）この場合のプロセスからのこの弱いリンクはオフになりません。 -彼の男はまだ機器を充電しないことを好む、なぜなら そのような能力を備えた技術は、人が不要であるという決定を下すことができます...プロセスの本質は何ですか：人は現在の状況を分析し（利用可能な情報に従って）、次に何をすべきかを決定し、この決定を即時の物理的行動または内部状態の変更のいずれかで修正します（「今、私は何をすべきかを知っています」または「明日それについて考えます...」）。 オートパイロットで行われる小さな自動決定（足をどこに置くか、どのポケットから電話を取得するか）、および注意を払う必要がある意識的な決定だけでなく、人の「クロック周波数」は1日あたり200〜300の決定にすぎません。 人がすべての決定を他の人と同期させる必要がある場合、つまり 共通の問題を同時に解決するために、個々の生産性は桁違いに低下します-1日に20回以上の会議を開催することはほとんどできませんが、情報を準備し、決定を実行するための時間が必要です（直接または同期を必要とする別の人を割り当てることによって）...グループウェアシステム（GWS）は、コラボレーションの効率を高めるように設計されており、同期イベントを非同期イベントに変換することでのみ実現できます。 トレーダーはすぐにGWSから完全な情報を受け取り、次の決定を下す必要があります。 同時に、GWSはオペレーティングシステムのタスクスケジューラーのように動作し、人々はスーパーマーケットのレジ係のように動作します-誰もが自分の能力の限界まで仕事をします（顧客のターン、つまり「タスク」の場合）、自分のキューでのみ動作し、同僚とのやり取りに邪魔されることなく（近隣のレジ係「レナ、5tyschに連絡する」などのやり取りは、すぐに2つのキューをすぐに停止します）、同僚は非同期で仕事をしなければなりません-コイン、レジ、商品を交換します 棚の上、ホールの買い物客など。



したがって、GWSでは、必要な最大システムパフォーマンス（システムユーザーの200倍）を見積もることができます。 もちろん、実際には、このようなパラメーターは非常によく発達した組織プロセスでのみ必要になります。 特にすべてのイベントがGWSに反映されているわけではないため、小規模オフィスや企業（100人まで）の場合、一般的には誰でも1日あたり200〜300のソリューションになります。 私たちは、1日あたり数千人が、ほぼすべての業界で、周辺の技術の発展に関係なく、典型的なオフィスの現在のすべてのニーズを（余裕を持って）カバーすると想定しています。



まだここにいる場合は、これをコンピューター言語に翻訳し始めます。 GWSのイベントまたはタスクとは何ですか？ メールメッセージ、カレンダーイベント、トラッカーのタスク、サイトのアプリケーション/アカウントなど。 ほとんどの場合、データベース内のそのようなファイルまたはレコードのサイズは、単位から数十KBです。 カレンダー（VTODOタスクまたはVEVENTイベントを内部に含むVCALENDAR形式のicsファイル）の数年-700バイトのタスクの平均サイズを計算しました。 フォーラムの投稿-1.5 KB。 内部wikiページ-4 Kb。 テクニカルサポートの文字は12 KBです（多くの場合、添付ファイル、つまりテキスト自体の平均サイズははるかに小さくなっています）。 このサイズを使用すると、1人の従業員の新しい情報の量を1日に1 MBで、オフィス全体で1日に50 MB以下で見積もることができます（多くのGWS要素が複数の受信者に宛てられている場合）。 ボリュームが大きい場合、タスクのかなりの部分が完了することはありません-単に物理的に処理する時間がありません-読んだり永久にハングしたりせずに削除されます（または同じように「処方箋のために」自動クローズ/アーカイブします） このような大量の情報を使用して、最新のPCに基づくGWSサーバーは、タスクをRAMに数か月間キャッシュし、1人の従業員のすべてのタスクを1秒未満で「出荷」し、オフィス全体のすべてのタスクをディスク上のオンラインアクセスに数年間保存できます。など データベース形式、使用されるプロトコル、使用されるサーバーおよびクライアントソフトウェアに応じて、これらのパラメーターは大幅に異なる場合があり、桁違いに異なる場合がありますが、通常のPCの能力でこれらのタスクに十分な余裕があることも明らかです。 そのため、同じタスクをより強力でないハードウェアで実行しようとすることができます。



PCの場合、そのような小さなボリュームとキャッシュの使用によるサーバーパフォーマンスは無制限と見なすことができますが、コントローラーの場合、数値は次のとおりです：80 MHzのCortex-M3は、16 MB / sの速度でSDRAMメモリをコピーします（DMAを使用せずにプロセッサ手段を使用）、TCP /を送信します4〜5 MB / sの速度を備えた100 Mbpsの組み込みイーサネットコントローラーを介したIPデータ（DMAを使用しない、つまり最適化の予約があります）。 理想的には、コントローラーは数分ですべてのカレンダーを同期し、個々のユーザーにとっては、これは一般に数秒で実行できることがわかりました。 しかし、実際には、プロトコルとシナリオによっては、すべてが通常理想からかけ離れています。



イベント/タスクを操作するために、ユーザーがWebDAV / CalDAVプロトコル（デスクトップPCのOutlook、Evolution、SunBird、Thunderbird + Lightningなど、iPhone / iPadのiCALなど）でカレンダークライアントを使用するとします。 、およびサーバー、それぞれ、これらのプロトコルをサポートするWebサーバー。 ただし、クライアントソフトウェアのパフォーマンスはテストせず（最新のPCでは十分であることは明らかです）、特定のGWSモデルのパフォーマンスはテストしません（大幅に遅くなることは明らかです）が、このタイプのタスクのネットワーク操作におけるコントローラーとPCの力の比率はテストしません。 カレンダーを同期する場合、クライアントソフトウェアはいくつかのHTTP / WebDAVコマンド（OPTIONS、PROPFIND、GET、PUT）を使用して、ほとんどの時間をPROPFINDコマンドに費やし、指定された条件を満たすサーバー上のイベントのリストからサブセットを選択します。 原則はメールの受信時とほぼ同じです-「新機能」が検出され、新しいメールがダウンロードされます（さらに、メールとは異なり、たとえばNNTPニュースのように）、サーバー上にないものが検出され、PUTコマンドによって送信されます。 簡単にするために、最初の段階では、ApacheBenchでGETのみをテストします。 1つのタスクを受信する最適でないクライアントをシミュレートして、単一のGETリクエストで多数の並列の個別の短い接続を開始しましょう。 キープアライブモードで複数のGETを使用して長い接続を実行し、PROGETをmultigetでシミュレートします。 各テストでは、数百の短いファイルを受け取り、1日または数日ですべてのタスクを受け取る個々のユーザーの同期セッションをシミュレートします。



鉄 4GB RAMと6x6 cmのARM搭載HonixBoxを搭載したオフィスPCと経済的なAMD E350プロセッサ（消費電力は最初のPentiumま​​たは最新のAtomに近く、最初のPentiumよりも2桁高く、Atomよりも大幅に高い）と比較します。 Cortex-M3（TI LM3S9B95）および8 MBのRAM。 それらは同じキャビネット内の同じ100Mbitスイッチに接続され、abが実行されている同じオフィス内のコンピューターからさらに2つのスイッチ（ギガビット）で分離され、クライアントを模倣します。



柔らかい Windows用のnginx / 1.0.14サーバー（現在の安定ビルド）として、Windows 8ベータ64ビットはPC上で実行されます。 HonixBox-自家製のコンパイラによってコンパイルされた自家製のOS上の自家製のWebサーバー（このタスクに対する特別な最適化なし-サーバーはHonixBoxの主要な「職業」であるネットワーク統計を提供するために作成されました。約500バイトのコードがシステム全体のアセンブラーで作成され、 HonixBoxの元のタスクは非常に単純だったため、それ以外はすべて最適化なしでFortで記述されています。これがコントローラーに実装された理由です。



テスト中です。 最初は、HonixBox（現在のHonixBoxの設定と要約統計を含むページを表示する小さなスクリプト）およびphpInfo（）でphpInfo（）を実行するために「/」を要求しましたが、FastCGIモードのWindowsでのPHPはnginxの実行中に500要求まで生き残れません-それは飛びます。 特にWebDAVのカレンダーは静的ファイルのセットであるため、静的ファイルに切り替えました（私の人生で初めてnginxを実行しました）。



ab -n 500 -c 100 192.168.0.156/favicon.ico（VTODOに近いサイズのHonixBox上の唯一のファイル。nginxでは、短いindex.htmlをリクエストします）-一度に100人のクライアントが500個のタスクを取得することをシミュレートします。



Nginxの結果：

テストにかかった時間：1.994990秒

完全なリクエスト：500

失敗したリクエスト：0

書き込みエラー：0

転送された合計：181000バイト

転送されるHTML：75500バイト

1秒あたりのリクエスト数：250.63 [＃/ sec]（平均）

リクエストあたりの時間：398.998 [ms]（平均）

リクエストごとの時間：3.990 [ms]（平均、すべての同時リクエスト全体）

転送速度：88.22 [キロバイト/秒]受信



HonixBox結果：

テストにかかった時間：10.466127秒

完全なリクエスト：500

失敗したリクエスト：0

書き込みエラー：0

転送された合計：211500バイト

転送されるHTML：159000バイト

1秒あたりのリクエスト：47.77 [＃/秒]（平均）

リクエストあたりの時間：2093.225 [ms]（平均）

リクエストごとの時間：20.932 [ms]（平均、すべての同時リクエスト全体）

転送速度：19.68 [Kバイト/秒]受信



コントローラーに対するPCの5倍の優位性。 両方のケースで最終転送レートが低いことに注意してください-わずか20-90 KB / sです。 ほとんどの場合、速度は主に多くのTCP接続のインストール/切断の遅延によって制限されます（当事者は互いに確認を待っています）。 ただし、1秒あたりのリクエスト数は、カレンダーの同期または電子メールの受信の一般的な速度と一致しています。



-cを削除し、 -k （キープアライブ）を追加します-Nginxは毎秒259リクエスト、HonixBoxは52に加速されます。 シングルスレッドバージョン（個々のクライアントは、Nginxでは2秒、HonixBoxでは10秒で500タスクを受け取ります）。 -c 10を追加します（10個のクライアントが一度に50個のタスクを取得します）-Nginxは最大424 s / sの速度になり、HonixBoxは52のままで、今回は8回失われます。



結果は私が予想したよりも悪いです-WindowsでApacheBenchに何か問題があったという疑いさえありましたが、PCとコントローラーの力の最終的な比率はおそらく「ab」に依存しません。 そして、制限要因はプロセッサ速度ではなく、ネットワーク（これら2台のマシン間のFTP経由では、11MB / sの速度は上記のテストの標準速度の100倍ですが）およびさらに多くの作業スキーム-多くの小さなオブジェクト、個別のHTTP要求によって受信されます。 さて、そして最も重要なこととして、PCサーバーとコントローラーサーバー間の発射速度の差は、予想どおり5〜8倍であり、少なくとも50倍ではありませんが、コントローラー上のソフトウェアには未処理の最適化スペースがあり、PC未使用電力の膨大なリザーブ-Nginxはこのテストで負担をかける必要がなく、主にI / Oを待っていました。 しかし、現在のバージョンでは、両方のサーバーは、たとえば実際のWebDAVサーバーを備えたLightningで作業している場合に通常観察される速度（またはさらに遅い速度）でデータを発行します。 つまり ユーザーは違いに気付かないでしょう。 Groupwareモードで実際の作業でPCとコントローラーを比較することはさらに興味深いでしょう。 私以外の誰かが興味を持っているなら、次回もやります。