дело в том, что эксперт вообще не сможет ходить чаще чем в 1 секунду за информацией. Так уж работают связки МT4 <-> wininet.dll<-> сервер.
Ну будет клиент долбить сервак запросами через каждую секунду. Ну и что? на то он и сервак, чтоб любой груз выдерживать. Представте как гуглы долбятся или вконтакте.
Я тестировал для проверки на 20 машинах + на каждой запущено по 3 терминала в этих связках запрос-ответ причем запросы при прогоне из тестера!
И вполне здорово себя чувствовали все участники эксперимента (и провайдер тоже :). Единственное, что медленно тест происходит. Тик обрабатывается раз в секунду. Но и это не такая большая проблема.
Поэтому такие системы (в которых некий блок кода вынесен в интернет) вполне рабочие.
А чтобы тест нормально отрабатывался в такой связке, я данные просто сбрасываю в отдельный файл с timestamp в названии файла. В итоге после первого прогона тестер складывает все данные в директории. Второй прогон уже летит даже быстрее чем если бы эти данные были в базе данных на локальной машине. Правда файлов может оказаться довольно много.
и не должно наблюдаться.
дело в том, что эксперт вообще не сможет ходить чаще чем в 1 секунду за информацией. Так уж работают связки МT4 <-> wininet.dll<-> сервер.
Ну будет клиент долбить сервак запросами через каждую секунду. Ну и что? на то он и сервак, чтоб любой груз выдерживать. Представте как гуглы долбятся или вконтакте.
Я тестировал для проверки на 20 машинах + на каждой запущено по 3 терминала в этих связках запрос-ответ причем запросы при прогоне из тестера!
И вполне здорово себя чувствовали все участники эксперимента (и провайдер тоже :). Единственное, что медленно тест происходит. Тик обрабатывается раз в секунду. Но и это не такая большая проблема.
Поэтому такие системы (в которых некий блок кода вынесен в интернет) вполне рабочие.
为了使测试在这样的组合中正常工作，我只是将数据转储到一个单独的文件中，文件名中带有时间戳。结果是，在第一次运行后，测试人员将所有的数据堆积在目录中。第二次运行的速度比本地机器上的数据库中的数据还要快。然而，可能有相当多的文件。
А чтобы тест нормально отрабатывался в такой связке, я данные просто сбрасываю в отдельный файл с timestamp в названии файла. В итоге после первого прогона тестер складывает все данные в директории. Второй прогон уже летит даже быстрее чем если бы эти данные были в базе данных на локальной машине. Правда файлов может оказаться довольно много.
原则上作为一种选择...这只是介于一次接受所有数据或一次接受一点但经常接受的东西。
最主要的是，任务设置越精确，在速度方面优化的机会就越大。
例如，对于一条指标线，250000条*8字节（条形时间）+8字节（线值）~4MB的信息。
1.时间并不是所有指标都需要的。
2.报价可以被压缩。时间也可以被压缩））））
3.没有必要每次都传送所有的报价。有一种更经济的变体。在初始化过程中，指标登录到服务器并传输一大块数据。服务器返回一些与收到的数据集和收到该数据的客户端相关的句柄。在指示器工作时，它定期发送有关零条的信息，以便纠正其上的当前读数。当条形图关闭时，指标应将条形图的最后信息发送到服务器，服务器将返回关闭条形图的值。当连接被解除初始化/断裂时，服务器将释放分配的句柄并销毁数据集（或者不销毁，随你喜欢）。
4.此外，指标可以在客户端缓存收到的指标值（它们可以与压缩的数据块一起存储，根据这些数据块来计算）。
UPD：你不能在所有的点位上都重新计算指标，因为很多时候点位是在+1-1-1+1-1-1的流程中 - 你真的只需要计算2次指标。
1. Время нужно не для всех индикаторов.
是的，但现在我们谈论的是一个一般的案例。
2.报价可以被压缩。时间也可以被压缩））））
抛给我一个想法。
3.没有必要每次都传送所有的报价。有一种更经济的变体。在初始化过程中，指标登录到服务器并传输一大块数据。服务器返回一些与收到的数据集和收到该数据的客户端相关的句柄。在指示器工作时，它定期发送有关零条的信息，以便纠正其上的当前读数。当条形图关闭时，指标应将条形图的最后信息发送到服务器，服务器将返回关闭条形图的值。当连接被解除初始化/断裂时，服务器将释放分配的句柄并销毁数据集（或者不销毁，随你喜欢）。
这有点不清楚它如何能加快关于诱导线的数据传输。
4.此外，指标可以在客户端缓存收到的指标值（它们可以与压缩的数据块一起存储，根据这些数据块进行计算）。
类似于MT中已经实现的方式 - IndicatorCounted()。我将为这种目的开出我自己的类似功能。
UPD：你可能根本不需要对所有点位重新计算指标，因为很多时候点位是在+1-1-1-1-1-1-1的流程中--事实上你只需要计算2次指标。
换句话说--我们现在已经开始为电感器解决一个问题。同步和传输历史记录条 :)
也许我们应该建议他们为我们做这样的服务！"。
这是一个有趣的想法。 让服务器存储一个具有相同开盘/收盘/最高/最低价格的工具。还有体积也是。它将像所有货币一样，根据所有的一般规则进行下载和同步。然后，它可以作为诱导器的生产线。
也许值得在酒吧同步的技术文件中朝这个方向挖掘。
1) 对带有指标的图表进行截图
2) 将屏幕截图文件上传到你的HTTP服务器上
3) 用户使用他们的登录名/密码登录并查看图像。
但这只在你只需要看一下指标的时候才好。:(
3.没有必要每次都传送所有的报价。有一种更经济的变体。在初始化过程中，指标登录到服务器并传输一大块数据。服务器返回一些与收到的数据集和发送该数据的客户端相关的句柄。在指示器工作时，它定期发送有关零条的信息，以便纠正其上的当前读数。当条形图关闭时，指标应将条形图的最后信息发送到服务器，服务器将返回关闭条形图的值。在取消初始化/中断连接时，服务器将释放分配的句柄并销毁数据集（或者不销毁，以你的喜好为准）。
恶心的变体--启动时，整个系统的终端速度变慢，或者你必须等待很长的时间才能加载（有些系统仍然在使用慢速通道，例如樟脑丸）。更好的做法是分小块下载信息，并将历史记录保存在用户的机器上，这样就只有新鲜的信息被发送到流量中，就像在最新版本中那样：http://xrust.land.ru/download/。
Подкиньте идейку
系列的第一个元素被明确地存储。然后我们对该系列进行微分，并使用熵编码。
恶心的变体
即使在DLL的情况下，最好也能分块给出信息，这样消费者就不必等待（"为什么？"），而且最后也很好 :)
即使在DLL的情况下，最好也是分块给出信息，这样消费者就不会遭受长时间的等待（"为什么？"），而且最后也很美 :)
按照我的理解，背景/异步加载意味着。这就是我所说的...