記事「リプレイシステムの開発(第62回):サービスの再生(III)」についてのディスカッション

 

新しい記事「リプレイシステムの開発(第62回):サービスの再生(III)」はパブリッシュされました:

この記事では、実際のデータを使用する際にアプリケーションのパフォーマンスに影響を及ぼす可能性のある「ティック過剰」の問題について取り上げます。このティック過剰は、1分足を適切なタイミングで構築するうえで支障となることがよくあります。

前の記事リプレイシステムの開発(パート61)サービスの再生(II)」では、シミュレーションモードを使用している際に私たちのシステムで発生している問題について説明しました。これは、必ずしも開発中のアプリケーションに重大な障害があるというわけではなく、システム全体の応答速度に起因するものです。応答が追いつかず、すべての受信データをアプリケーションが適切に処理できなかったため、一定の調整が必要になりました。もちろん、私たちのサービスが理想的なシナリオ通りに動作していないとしても、現実にはそうした理想的な状況が存在すること自体まれであることも理解しています。

私が導き出した最適な解決策は、シミュレーションにおける最大制限値を調整することでした。ただし、この記事ではその変更がどのような影響をもたらすのかを慎重に検証し、なぜそのアプローチを選択したのかについても詳しく解説します。さらに、開発中のアプリケーション外で生成された実データや外部シミュレーションデータに直接関係する要素もあります。意外に思われるかもしれませんが、特に先物契約においては、1分間に異常な数のティックや取引が集中するケースがあります。こうした状況では、取引サーバーに接続していても、MetaTrader 5プラットフォームが価格の変動を処理・表示する速度に問題が生じることがあります。この問題に直面したことがない方であれば、MetaTrader 5を実行しているハードウェアの性能不足やOSの不具合が原因だと考えるかもしれません。しかし残念ながら、そうした推測は完全に誤りであり、コンピューティングに関する理解が不十分な人々によって広まった誤解に過ぎません。

実際の取引サーバーに接続している状態でも大量のティックデータの処理にプラットフォームが苦戦していることを考えると、それをリプレイする場合にはさらに深刻な状況となります。タイミングの精度が大きく損なわれ、完全な惨事となるでしょう。そのため、プラットフォームの処理能力の限界が露呈したり、新たな問題を引き起こしたりしないよう、実データや外部シミュレーションデータに対しても上限を設ける必要があります。それでは、新しいコードがどのように構成されるかを見ていきましょう。


作者: Daniel Jose