2019.08.20 10:34:52.453 Trades 'xxxxx': modify order #107882836 buy limit 2.00 MIX-12.19 at 268725 sl: 0 tp: 0 expiration: day -> 268925, sl: 0 tp: 0 expiration: day placed for execution in 4.798 ms
2019.08.2111:50:32.805 Trades 'xxxxx': cancel order #107952550 sell limit 1.00 MAGN-12.19 at 39372 placed for execution in6.061 ms
2019.08.2111:52:12.262 Trades 'xxxxx': buy limit 2.00 MAGN-12.19 at 37298 placed for execution in6.727 ms
2019.08.2111:52:12.749 Trades 'xxxxx': cancel order #107952871 buy limit 2.00 MAGN-12.19 at 37298 placed for execution in6.176 ms
2019.08.2111:55:47.387 Trades 'xxxxx': cancel order #107941822 sell limit 1.00 UCHF-12.19 at 0.9774 placed for execution in5.216 ms
2019.08.2111:56:12.511 Trades 'xxxxx': buy limit 2.00 BR-6.20 at 57.39 placed for execution in6.865 ms
2019.08.2111:56:12.801 Trades 'xxxxx': modify order #107953158 buy limit 2.00 BR-6.20 at 57.39 sl: 0.00 tp: 0.00 expiration: day -> 57.68, sl: 0.00 tp: 0.00 expiration: day placed for execution in6.459 ms
2019.08.2111:56:13.076 Trades 'xxxxx': modify order #107953158 buy limit 2.00 BR-6.20 at 57.68 sl: 0.00 tp: 0.00 expiration: day -> 58.85, sl: 0.00 tp: 0.00 expiration: day placed for execution in6.086 ms
2019.08.2111:56:13.180 Trades 'xxxxx': cancel order #107953158 buy limit 2.00 BR-6.20 at 58.85 placed for execution in5.180 ms
2019.08.2111:56:13.429 Trades 'xxxxx': sell limit 1.00 MAGN-12.19 at 39368 placed for execution in6.836 ms
2019.08.2111:56:29.700 Trades 'xxxxx': modify order #107953162 sell limit 1.00 MAGN-12.19 at 39368 sl: 0 tp: 0 expiration: day -> 39366, sl: 0 tp: 0 expiration: day placed for execution in6.926 ms
2019.08.2111:56:29.962 Trades 'xxxxx': modify order #107952222 buy limit 1.00 MIX-6.20 at 261875 sl: 0 tp: 0 expiration: day -> 261925, sl: 0 tp: 0 expiration: day placed for execution in6.418 ms
2019.08.2111:56:50.775 Trades 'xxxxx': modify order #107952222 buy limit 1.00 MIX-6.20 at 261925 sl: 0 tp: 0 expiration: day -> 262200, sl: 0 tp: 0 expiration: day placed for execution in5.180 ms
非同期で注文を 送るので、何が起こっているのかがよくわかる
Установка ордера
2019.08.16 10:00:02.189 Trades 'ххххх': sell limit 2.00 UJPY-12.19 at 108.33
Если нет ответа сервера в OnTradeTransacrtion (должен прийти тикет ордера), то срабатывает каждую секунду функция CheckOrders
2019.08.16 10:00:03.562 FCS_Trader (UJPY-9.19,M1) CheckOrders: Не получен билет Sell ордера. Ожидание продолжается...
2019.08.16 10:00:04.576 FCS_Trader (UJPY-9.19,M1) CheckOrders: Не получен билет Sell ордера. Ожидание продолжается...
2019.08.16 10:00:05.590 FCS_Trader (UJPY-9.19,M1) CheckOrders: Не получен билет Sell ордера. Ожидание продолжается...
2019.08.16 10:00:06.604 FCS_Trader (UJPY-9.19,M1) CheckOrders: Не получен билет Sell ордера. Ожидание продолжается...
2019.08.16 10:00:07.618 FCS_Trader (UJPY-9.19,M1) CheckOrders: Не получен билет Sell ордера. Ожидание продолжается...
2019.08.16 10:00:08.632 FCS_Trader (UJPY-9.19,M1) CheckOrders: Не получен билет Sell ордера. Ожидание продолжается...
2019.08.16 10:00:09.646 FCS_Trader (UJPY-9.19,M1) CheckOrders: Не получен билет Sell ордера. Ожидание продолжается...
А вот Сервер МТ5 ответил, что он проверил ордер и присвоил ему тикет
2019.08.16 10:00:09.986 Trades 'ххххх': accepted sell limit 2.00 UJPY-12.19 at 108.33
А здесь, Сервер МТ5 сообщил, что мой ордер отослан на Биржу
2019.08.16 10:00:10.238 Trades 'ххххх': sell limit 2.00 UJPY-12.19 at 108.33 placed for execution in 8050.533 ms
Если вы хотите создать брокерскую компанию или расширить существующий бизнес — закажите институциональную мультирыночную платформу MetaTrader 5! С ее помощью вы сможете организовать успешное обслуживание трейдеров на Форексе, фондовой бирже и рынках фьючерсов. В составе MetaTrader 5 есть все необходимые компоненты для организации брокерского...
Анализировал с владельцем MT5-сервера тормоза торговых приказов. Запускался OrderSend-Test2.mq5 в том же месте, где MT5-сервер стоит. Т.е. нулевой пинг. Демо, все внутри. Изучались логи MT5-сервера (2170) и MT5-клиента (2280). Логи сервера не буду приводить, просто словами опишу. Думаю, результаты буду интерсны всем, т.к. это поможет раскрыть...
:)
政治的に正しいことを言ってるんだ。
私たちはMT5にお金を払っていませんが、Openersはお金を払っているので、Openersは以下のような権利があります。
テクニカルサポートまで :)そうですね...有罪確定ですね :)
あなたは正しいかもしれない(政治的に正しい) )))
opryvyshkaに権利があれば、それ自体をMT5経由で取引させればよい。
MT5にはトレーダー用のサポートがないので、他の手を探す必要がある )
あなたは正しいかもしれない(政治的に正しい) )))
Openerに権利があるなら、彼自身にMT5を通して取引させればいい。
MT5にはトレーダー用のサポートがないので、他の手を探す必要がある )
オプリバシカの記録」を掲載したのには理由が あります。
2019.08.20 10:34:52.453 Trades 'xxxxx': modify order #107882836 buy limit 2.00 MIX-12.19 at 268725 sl: 0 tp: 0 expiration: day -> 268925, sl: 0 tp: 0 expiration: day placed for execution in 4.798 ms
私(自宅)からOpenwashkaのMT5サーバーまで、ネットワーク接続が最高 レベルであることを示しています。
一例を 挙げると自宅からの平均速度(5-7ms)
非同期で注文を 送るので、何が起こっているのかがよくわかる
Установка ордера 2019.08.16 10:00:02.189 Trades 'ххххх': sell limit 2.00 UJPY-12.19 at 108.33 Если нет ответа сервера в OnTradeTransacrtion (должен прийти тикет ордера), то срабатывает каждую секунду функция CheckOrders
端末には、取引所からの 発注に関する返答の ログが残らないため(非同期注文の場合)
この確認はOnTradeTransacrtionでのみ 取得することができ、そのためさらに時間が かかることがあります。
2019.08.16 10:02:39.777 Trades 'ххххх': modify order #107744605 sell limit 2.00 UJPY-12.19 at 108.29 sl: 0.00 tp: 0.00 expiration: day -> 105.73, sl: 0.00 tp: 0.00 expiration: day placed for execution in 40075.505 ms 2019.08.16 10:02:40.768 FCS_Trader (UJPY-9.19,M1) ProcessOrders: Sell ордер в процессе модификации. Билет = 107744605 2019.08.16 10:02:41.786 FCS_Trader (UJPY-9.19,M1) ProcessOrders: Sell ордер в процессе модификации. Билет = 107744605
つまり、もう2秒の応答が期待できる。
結論は明白です!
MT5サーバーは、ピーク時の負荷、クライアントによる大量の注文送信に対応できない。
追加
一番悲しいのは、オトクリヴァシカには700人のアクティブなクライアントがいるのに、MT5サーバーは7台しかないことです。
したがって、1サーバーあたり(すべてのアクティブなクライアントがMT5を介して動作していると仮定した場合)
19700/7 = 2814.29 クライアントとなり、平均的なサーバーの基準からすると、これほど多くのリクエストを処理するには、ほんのわずかな量です。
開封の儀」を公開したのには理由が あります。
これは、私(自宅)からOpenerのMT5サーバーまで、ネットワーク接続が最高 レベルであることを示しています。
一例を 挙げると自宅からの平均速度(5-7ms)
非同期で注文を 送るので、何が起こっているのかがよくわかる
端末には、取引所からの 発注に関する回答のログが残らないため(非同期注文の場合)
この確認はOnTradeTransacrtionでのみ受け取ることができるため、さらに時間がかかる場合が あります。
つまり、応答まであと2秒待たなければならなかったのです。
結論は明白です!
MT5サーバーは、ピーク時の負荷、クライアントによる大量の注文送信に対応できない。
追加
一番悲しいのは、オトクリヴァシカには700人のアクティブなクライアントがいるのに、MT5サーバーは7台しかないことです。
したがって、1サーバーあたり(すべてのアクティブなクライアントがMT5を介して動作していると仮定した場合)
19700/7 = 2814.29 クライアントとなり、平均的なサーバーの基準からすると、これほど多くのリクエストを処理するには、ほんのわずかな量です。
デフォルトでは、すべてのクライアントが最小限のPingでMT5サーバーに接続し、ターミナルもそれを選択することが判明しました。その結果、一番pingの速いサーバーでジャムってしまうんです。
Pingが最速でない他のサーバーに強制的に切り替えてみたことはありますか?
すべてのMT5クライアントは、デフォルトで最小のPingを持つサーバーに接続されることが判明し、ターミナルは自分自身を選択します。その結果、最速のPingサーバーでトラフィックジャムが発生します。
Pingが最速でない他のサーバーに強制的に切り替えてみましたか?
端末はpingだけでなく、サーバーの負荷でも切り替わると思うのですが...。
しかし、具体的にどのように機能するのか、私にはわかりません。
別のサーバーに切り替えてみましたが、結果は同じです
サーバーではなく、後ろに1台のサーバーがあるアクセスポイントです。
カッコイイ!どうしてわかるんですか?