дело в том, что эксперт вообще не сможет ходить чаще чем в 1 секунду за информацией. Так уж работают связки МT4 <-> wininet.dll<-> сервер.
Ну будет клиент долбить сервак запросами через каждую секунду. Ну и что? на то он и сервак, чтоб любой груз выдерживать. Представте как гуглы долбятся или вконтакте.
Я тестировал для проверки на 20 машинах + на каждой запущено по 3 терминала в этих связках запрос-ответ причем запросы при прогоне из тестера!
И вполне здорово себя чувствовали все участники эксперимента (и провайдер тоже :). Единственное, что медленно тест происходит. Тик обрабатывается раз в секунду. Но и это не такая большая проблема.
Поэтому такие системы (в которых некий блок кода вынесен в интернет) вполне рабочие.
А чтобы тест нормально отрабатывался в такой связке, я данные просто сбрасываю в отдельный файл с timestamp в названии файла. В итоге после первого прогона тестер складывает все данные в директории. Второй прогон уже летит даже быстрее чем если бы эти данные были в базе данных на локальной машине. Правда файлов может оказаться довольно много.
и не должно наблюдаться.
дело в том, что эксперт вообще не сможет ходить чаще чем в 1 секунду за информацией. Так уж работают связки МT4 <-> wininet.dll<-> сервер.
Ну будет клиент долбить сервак запросами через каждую секунду. Ну и что? на то он и сервак, чтоб любой груз выдерживать. Представте как гуглы долбятся или вконтакте.
Я тестировал для проверки на 20 машинах + на каждой запущено по 3 терминала в этих связках запрос-ответ причем запросы при прогоне из тестера!
И вполне здорово себя чувствовали все участники эксперимента (и провайдер тоже :). Единственное, что медленно тест происходит. Тик обрабатывается раз в секунду. Но и это не такая большая проблема.
Поэтому такие системы (в которых некий блок кода вынесен в интернет) вполне рабочие.
このような組み合わせでテストが正しく動作するように、私は単純にデータを別のファイルにダンプし、ファイル名にタイムスタンプを付けました。その結果、最初の実行後、テスターはディレクトリ内の全データをスタックする。2回目の実行は、データがローカルマシンのデータベースにある場合よりもさらに高速に実行されます。ただし、ファイル数はかなり多いかもしれません。
А чтобы тест нормально отрабатывался в такой связке, я данные просто сбрасываю в отдельный файл с timestamp в названии файла. В итоге после первого прогона тестер складывает все данные в директории. Второй прогон уже летит даже быстрее чем если бы эти данные были в базе данных на локальной машине. Правда файлов может оказаться довольно много.
原則的にオプションとして...一度にすべてのデータを取り込むか、少しずつでも頻繁に取り込むか、その中間のようなものです。
要は、タスクセットの精度が高ければ高いほど、スピードの面で最適化できる可能性が高いということです。
例：1つのインジケーターラインの場合 250000バー*8バイト（バー時間）+8バイト（ライン値） ~ 4 mbの情報。
1.時間はすべての指標に必要なものではありません。
2.引用符は圧縮することができます。時間も圧縮できる)))
3.すべての見積書を毎回送信する必要はない。より経済的なバリエーションもあります。初期化の際、インジケータはサーバにログインし、大きなデータチャンクを送信する。サーバーは、受信したデータセットとこのデータを受信したクライアントに関連する何らかのハンドルを返す。インジケーターが動作している間、ゼロバーの現在の読み取り値を修正するために、ゼロバーに関する情報を定期的に送信します。バーが終了するとき、インジケータはバーに関する最終情報をサーバーに送信し、終了したバーの値を返す必要があります。接続が解除されたり壊れたりすると、サーバーは割り当てられたハンドルを解放し、データセットを破棄します(破棄しないことも可能です)。
4.さらに、インジケータは、クライアント側で、受信したインジケータの値をキャッシュすることができる（それらは、それらが計算されたことに従って、圧縮されたデータブロックとともに格納することができる）。
UPD: 刻み目は+1 -1 -1 +1 -1 -1 の流れになることが非常に多いので、すべての刻み目でインジケーターを再計算することはできません。
1. Время нужно не для всех индикаторов.
はい、でも今は一般的なケースの話をしています。
2.引用符は圧縮することができます。時間も圧縮できる)))
アイデアを投げてください。
3.すべての見積書を毎回送信する必要はない。より経済的なバリエーションもあります。初期化の際、インジケータはサーバにログインし、大きなデータチャンクを送信する。サーバーは、受信したデータセットとこのデータを受信したクライアントに関連する何らかのハンドルを返す。インジケーターが動作している間、ゼロバーの現在の読み取り値を修正するために、ゼロバーに関する情報を定期的に送信します。バーが終了するとき、インジケータはバーに関する最終情報をサーバーに送信し、終了したバーの値を返す必要があります。接続が解除されたり壊れたりすると、サーバーは割り当てられたハンドルを解放し、データセットを破棄します(破棄しないことも可能です)。
これでは、誘導線に関するデータの転送を高速化することができるのか、ちょっとわからない。
4.さらに、インジケータは、クライアント側で、受信したインジケータ値をキャッシュすることができる（それらは、それらが計算されたことに従って、圧縮データブロックと一緒に格納することができる）。
MTのIndicatorCounted()で既に実装されている方法と同様です。そのような目的のために、私自身も同様の機能を処方することにしています。
UPD: 刻み目は+1 -1 -1 -1 -1 の流れになることが非常に多いので、全ての刻み目で再計算する必要はないかもしれませんが、実際には2回だけ計算する必要があります。
つまり、今、インダクタの問題解決に着手しているのです。ヒストリーバーの同期と送信 :)
こんなサービス作ってください！」と提案してみるのもいいかもしれませんね。
面白いアイデアですね。 サーバーに、open/close/high/loの価格が等しい楽器を保存させます。そして、ボリュームも。他の通貨と同様、一般的なルールに従ってダウンロードされ、同期されます。そして、それを誘導装置のラインとして利用することができます。
バーシンクロの技術資料でこの方向性を掘り下げてみる価値はあるかもしれません。
1) インジケータを表示したチャートのスクリーンショットを作成します。
2) スクリーンショット・ファイルをHTTPサーバーにアップロードする
3) ユーザーはログイン/パスワードでログインし、画像を見る。
しかし、これはインジケータを見るだけでいいという場合に限ります。:(
3.すべての見積もりを毎回送信する必要はない。より経済的なバリエーションもあります。初期化時にインジケータはサーバにログインし、大きなデータチャンクを送信する。サーバーは、受信したデータセットとこのデータを送信したクライアントに関連する何らかのハンドルを返す。インジケーターが動作している間、ゼロバーの現在の読み取り値を修正するために、ゼロバーに関する情報を定期的に送信します。バーが終了するとき、インジケータはバーに関する最終情報をサーバーに送信し、終了したバーの値を返す必要があります。接続の初期化/切断時に、サーバーは割り当てられたハンドルを解放し、データセットを破棄する（またはしない、どちらか好きなほうを選択）。
嫌なバリエーション - 起動時にシステム全体がターミナルでスローダウンしたり、ロードに非常に長い時間待たされたりします（一部のシステムでは、モスボールなどの低速チャネルがまだ使用されています）。最新バージョンで行われているように、情報を小分けにしてダウンロードし、ユーザーのマシンに履歴を保存して、新鮮な情報だけがトラフィックに送られるようにする方がずっと良いのです:http://xrust.land.ru/download/
Подкиньте идейку
系列の最初の要素が明示的に格納される。そして、系列を微分し、エントロピー符号化を用いる。
ムカムカバリアント
DLLの場合でも、消費者が待たずに済むように、情報をチャンクで与えることが望ましく（「WHY?）
DLLの場合でも、消費者が長い間待たされることがないように、情報を塊で与えることが望ましく（「なぜ？）
私が理解するバックグラウンド/非同期ロードは、それを意味します。そういうことなんだ...。