エラー、バグ、質問 - ページ 2692 1...268526862687268826892690269126922693269426952696269726982699...3185 新しいコメント Andrey Dik 2020.04.02 00:04 #26911 Artyom Trishkin: では、どうでしょう...。 ここで私は知らない...安価なVPSに支払われ、0使用、MQからのVPSは、ところで、このブローカーにそのようなPingを与えていない、そうでなければ私はそれを使用して幸せだったかもしれません。 Andrey Khatimlianskii 2020.04.02 00:49 #26912 Andrey Dik: MQのVPSはこのブローカーへのPingを出さないので、そうでなければ喜んで使ったかもしれません。 レナートは以前、「サーバーはこのように自分自身の負荷を調節している」と説明したことがある。 つまり、自分たちが過負荷になると、他の販売店に顧客を逃がすのである。 おそらく、正しいサーバーへの自動的なソフトウェア切り替えが有効なのでしょう。 Roman 2020.04.02 02:57 #26913 Andrey Khatimlianskii: レナートは以前、「サーバーはこのように自分自身の負荷を調節している」と説明したことがある。 つまり、自分たちが過負荷になれば、クライアントを他の拠点に蹴落とすということだ。 おそらく、正しいサーバーへの自動的なソフトウェア切り替えが有効なのでしょう。 へっへっへ、サーバーの実装が違うのか...。 つまり、サーバーは垂直方向にスケールするのではなく、クラスタに参加して水平方向にスケールし、愚かにもクライアントを別のサーバーにリダイレクトしてしまうのです。 pingが重要な優先事項であるこのケースには、適切な実装ではありません。 Andrey Dik 2020.04.02 07:25 #26914 Andrey Khatimlianskii: レナートは以前、「サーバーはこのように自分自身の負荷を調節している」と説明したことがある。 つまり、自分たちが過負荷になれば、クライアントを他の拠点に蹴落とすということだ。 おそらく、正しいサーバーへの自動的なソフトウェア切り替えが有効なのでしょう。 嗚呼、そういうことか...。 開発者の皆様、この問題は非常に深刻ですので、くれぐれもご注意ください。 必要なら個人でログを渡しますよ。 Andrey Khatimlianskii 2020.04.02 07:53 #26915 Roman: 重要な優先順位がpingであるこのケースには、適切な実装ではありません。 50msのキューがあるほどサーバーがビジー状態なら、1msのpingにどんな喜びがあるのでしょう? 今の実装を擁護しているわけではなく、あくまで推論です。 Andrey Dik 2020.04.02 09:08 #26916 Andrey Khatimlianskii: 50msのキューがあるほどサーバーがビジー状態なら、1msのpingにどんな喜びがあるのでしょう? 今の実装を擁護しているわけではなく、あくまで推論です。 mt5サーバーが対応できないのは残念ですが...。それに対応できるプラットフォームに移行する必要があるでしょう。 Renat Fatkhullin 2020.04.02 09:22 #26917 端末のログを見てみてください。 すべての再接続、切断の理由、ネットワーククラスタの再スキャンがそこに表示されます。 再接続は数秒ごとではなく、数時間ごとに自動的に評価されます。そうしないと、端末がサーバー間を常にホッピングするようなラウンドになってしまうからです。 Roman 2020.04.02 10:59 #26918 Andrey Khatimlianskii: 50msのキューがあるほどサーバーがビジー状態なら、1msのpingにどんな喜びがあるのでしょう? 今の実装を擁護しているわけではなく、あくまで推論です。 サーバーに負荷がかからないようにするためには、サーバーの垂直スケーリング方式を構築する必要があります。 つまり、サーバーの負荷がピークに達した時、例えば80%の負荷の時に、自動的に鉄の電力が追加されるのです。 この力はプロバイダーが多く持っており、プロバイダーの容量を1台や複数台のサーバーで選ぶのは現実的ではありません。 サーバーのピーク負荷が減少すると、鉄の付加容量は以前のパラメーターに減少します。 このスケーリングでは、クライアントが別のサーバーにリダイレクトされることはありません。 別のサーバーへのリダイレクトは、サーバーがダウンする場合や何らかの障害が発生した場合など、緊急の場合に行われます。 そして、MQはおそらく、別のサーバへのリダイレクトが重要でないWebサーバ向けに設計された水平スケーリングで実装を構築したのでしょう。 Igor Zakharov 2020.04.02 11:22 #26919 テキストがグレー(他の色も可)の長方形の下にあるとき、アウトラインとカラーが「侵食」される。 の文字を大きくしています。 Andrey Dik 2020.04.02 13:00 #26920 Renat Fatkhullin: 端末のログを見てみてください。 すべての再接続、切断の理由、ネットワーククラスタの再スキャンがそこに表示されます。 再接続は数 秒ごとではなく、数時間ごとに自動的に評価 されます。そうしないと、端末がサーバー間を常にホッピングするようなラウンドになってしまうからです。 はい、サーバー1への接続が失われ、はい、サーバー3へ接続しましたが、なぜ再びサーバー1へ自動的に接続しないのか不明です。 いずれにせよ、現代のアルゴトレーディングは四半期に一度の取引ではないので、数時間接続が途絶えても構わないだろう。サーバー3が接続されると、端末がフリーズし、数分間相場が更新されないという現象が発生する。 サーバーとクライアントのビルドの違いが大きすぎるのが致命的なのでは? ブローカーはサーバーが2280、私の端末は2363です。 1...268526862687268826892690269126922693269426952696269726982699...3185 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
では、どうでしょう...。
ここで私は知らない...安価なVPSに支払われ、0使用、MQからのVPSは、ところで、このブローカーにそのようなPingを与えていない、そうでなければ私はそれを使用して幸せだったかもしれません。
MQのVPSはこのブローカーへのPingを出さないので、そうでなければ喜んで使ったかもしれません。
レナートは以前、「サーバーはこのように自分自身の負荷を調節している」と説明したことがある。
つまり、自分たちが過負荷になると、他の販売店に顧客を逃がすのである。
おそらく、正しいサーバーへの自動的なソフトウェア切り替えが有効なのでしょう。
レナートは以前、「サーバーはこのように自分自身の負荷を調節している」と説明したことがある。
つまり、自分たちが過負荷になれば、クライアントを他の拠点に蹴落とすということだ。
おそらく、正しいサーバーへの自動的なソフトウェア切り替えが有効なのでしょう。
へっへっへ、サーバーの実装が違うのか...。
つまり、サーバーは垂直方向にスケールするのではなく、クラスタに参加して水平方向にスケールし、愚かにもクライアントを別のサーバーにリダイレクトしてしまうのです。
pingが重要な優先事項であるこのケースには、適切な実装ではありません。
レナートは以前、「サーバーはこのように自分自身の負荷を調節している」と説明したことがある。
つまり、自分たちが過負荷になれば、クライアントを他の拠点に蹴落とすということだ。
おそらく、正しいサーバーへの自動的なソフトウェア切り替えが有効なのでしょう。
開発者の皆様、この問題は非常に深刻ですので、くれぐれもご注意ください。
必要なら個人でログを渡しますよ。
重要な優先順位がpingであるこのケースには、適切な実装ではありません。
50msのキューがあるほどサーバーがビジー状態なら、1msのpingにどんな喜びがあるのでしょう?
今の実装を擁護しているわけではなく、あくまで推論です。
50msのキューがあるほどサーバーがビジー状態なら、1msのpingにどんな喜びがあるのでしょう?
今の実装を擁護しているわけではなく、あくまで推論です。
mt5サーバーが対応できないのは残念ですが...。それに対応できるプラットフォームに移行する必要があるでしょう。
端末のログを見てみてください。
すべての再接続、切断の理由、ネットワーククラスタの再スキャンがそこに表示されます。
再接続は数秒ごとではなく、数時間ごとに自動的に評価されます。そうしないと、端末がサーバー間を常にホッピングするようなラウンドになってしまうからです。
50msのキューがあるほどサーバーがビジー状態なら、1msのpingにどんな喜びがあるのでしょう?
今の実装を擁護しているわけではなく、あくまで推論です。
サーバーに負荷がかからないようにするためには、サーバーの垂直スケーリング方式を構築する必要があります。
つまり、サーバーの負荷がピークに達した時、例えば80%の負荷の時に、自動的に鉄の電力が追加されるのです。
この力はプロバイダーが多く持っており、プロバイダーの容量を1台や複数台のサーバーで選ぶのは現実的ではありません。
サーバーのピーク負荷が減少すると、鉄の付加容量は以前のパラメーターに減少します。
このスケーリングでは、クライアントが別のサーバーにリダイレクトされることはありません。
別のサーバーへのリダイレクトは、サーバーがダウンする場合や何らかの障害が発生した場合など、緊急の場合に行われます。
そして、MQはおそらく、別のサーバへのリダイレクトが重要でないWebサーバ向けに設計された水平スケーリングで実装を構築したのでしょう。
テキストがグレー(他の色も可)の長方形の下にあるとき、アウトラインとカラーが「侵食」される。
の文字を大きくしています。
端末のログを見てみてください。
すべての再接続、切断の理由、ネットワーククラスタの再スキャンがそこに表示されます。
再接続は数 秒ごとではなく、数時間ごとに自動的に評価 されます。そうしないと、端末がサーバー間を常にホッピングするようなラウンドになってしまうからです。
はい、サーバー1への接続が失われ、はい、サーバー3へ接続しましたが、なぜ再びサーバー1へ自動的に接続しないのか不明です。
いずれにせよ、現代のアルゴトレーディングは四半期に一度の取引ではないので、数時間接続が途絶えても構わないだろう。サーバー3が接続されると、端末がフリーズし、数分間相場が更新されないという現象が発生する。
サーバーとクライアントのビルドの違いが大きすぎるのが致命的なのでは? ブローカーはサーバーが2280、私の端末は2363です。