Como posso acessar o peru remotamente? - página 5
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
и не должно наблюдаться.
дело в том, что эксперт вообще не сможет ходить чаще чем в 1 секунду за информацией. Так уж работают связки МT4 <-> wininet.dll<-> сервер.
Ну будет клиент долбить сервак запросами через каждую секунду. Ну и что? на то он и сервак, чтоб любой груз выдерживать. Представте как гуглы долбятся или вконтакте.
Я тестировал для проверки на 20 машинах + на каждой запущено по 3 терминала в этих связках запрос-ответ причем запросы при прогоне из тестера!
И вполне здорово себя чувствовали все участники эксперимента (и провайдер тоже :). Единственное, что медленно тест происходит. Тик обрабатывается раз в секунду. Но и это не такая большая проблема.
Поэтому такие системы (в которых некий блок кода вынесен в интернет) вполне рабочие.
Para que o teste funcione corretamente em tal combinação, eu simplesmente despejo os dados em um arquivo separado com um carimbo de data/hora no nome do arquivo. Como resultado, após a primeira corrida, o testador empilha todos os dados no diretório. A segunda corrida é ainda mais rápida do que se os dados estivessem no banco de dados da máquina local. No entanto, pode haver uma grande quantidade de arquivos.
А чтобы тест нормально отрабатывался в такой связке, я данные просто сбрасываю в отдельный файл с timestamp в названии файла. В итоге после первого прогона тестер складывает все данные в директории. Второй прогон уже летит даже быстрее чем если бы эти данные были в базе данных на локальной машине. Правда файлов может оказаться довольно много.
em princípio como uma opção... É apenas algo entre receber todos os dados de uma só vez ou um pouco de cada vez, mas com freqüência.
O principal é que quanto mais precisa for a tarefa definida, melhor será a chance de otimizá-la em termos de velocidade.
por exemplo, para uma linha indicadora 250000 barras*8 bytes (tempo de barra) + 8 bytes (valor da linha) ~ 4 mb de informação.
1. O tempo não é necessário para todos os indicadores.
2. As citações podem ser comprimidas. O tempo também pode ser comprimido))))
3. não é necessário transmitir todas as citações a cada vez. Existe uma variante mais econômica. Durante a inicialização, o indicador registra ao servidor e transmite um grande pedaço de dados. O servidor retorna alguma manipulação associada ao conjunto de dados recebidos e ao cliente que recebeu esses dados. Enquanto o indicador está funcionando, ele envia periodicamente informações sobre a barra de zero a fim de corrigir a leitura atual sobre ele. Quando a barra estiver fechando, o indicador deve enviar as informações finais sobre a barra para o servidor que devolverá o valor da barra fechada. Quando a conexão for desinicializada/ quebrada, o servidor liberará o cabo alocado e destruirá o conjunto de dados (ou não, como se quiser).
4. Além disso, o indicador pode armazenar no lado do cliente os valores recebidos do indicador (eles podem ser armazenados junto com o bloco de dados comprimido, de acordo com o qual eles são calculados).
UPD: Você não pode recalcular o indicador em todos os carrapatos, porque muitas vezes os carrapatos estão no fluxo de +1 -1 -1 -1 -1 -1 -1 -1 - você realmente precisa calcular o indicador apenas 2 vezes.
1. Время нужно не для всех индикаторов.
Sim, mas agora estamos falando de um caso geral.
2. As citações podem ser comprimidas. O tempo também pode ser comprimido))))
Atire-me uma idéia.
3. não é necessário transmitir todas as citações a cada vez. Existe uma variante mais econômica. Durante a inicialização, o indicador registra ao servidor e transmite um grande pedaço de dados. O servidor retorna alguma manipulação associada ao conjunto de dados recebidos e ao cliente que recebeu esses dados. Enquanto o indicador está funcionando, ele envia periodicamente informações sobre a barra de zero a fim de corrigir a leitura atual sobre ele. Quando a barra estiver fechando, o indicador deve enviar as informações finais sobre a barra para o servidor que devolverá o valor da barra fechada. Quando a conexão for desinicializada/ quebrada, o servidor liberará o cabo alocado e destruirá o conjunto de dados (ou não, como se quiser).
Isto é um pouco incerto como pode acelerar a transferência de dados sobre a linha induzida.
4. Além disso, o indicador pode armazenar no lado do cliente os valores do indicador recebido (eles podem ser armazenados junto com o bloco de dados comprimido, de acordo com o qual eles são calculados).
semelhante a como já está implementado em MT - IndicatorCounted(). Eu prescreveria minha própria função similar para tais propósitos.
UPD: Você pode não recalcular o indicador em todos os carrapatos, porque muitas vezes os carrapatos estão no fluxo de +1 -1 -1 -1 -1 -1 -1 -1 - na verdade, você só precisa calcular o indicador 2 vezes.
Em outras palavras - começamos agora a resolver um problema para os indutores. Sincronização e transmissão de barras de histórico :)
Talvez devêssemos propô-los para fazer tal serviço para nós!
É uma idéia interessante. Deixe o servidor armazenar um instrumento com o mesmo preço aberto/fechado/alto/alto/alto. E os volumes também. Ele será baixado e sincronizado de acordo com todas as regras gerais, como todas as moedas. E pode então ser usado como uma linha de indutores.
Pode valer a pena cavar nesta direção na documentação técnica de sincronização de barras.
1) fazer uma captura de tela do gráfico com o indicador
2) Carregue o arquivo de captura de tela para seu servidor HTTP
3) Os usuários fazem login usando seu login/passwords e olham a imagem.
Mas isto só é bom quando você precisa apenas olhar o indicador. :(
3. não é necessário transmitir todas as citações todas as vezes. Existe uma variante mais econômica. Durante a inicialização, o indicador entra no servidor e transmite um grande pedaço de dados. O servidor retorna alguma manipulação associada ao conjunto de dados recebidos e ao cliente que enviou esses dados. Enquanto o indicador está funcionando, ele envia periodicamente informações sobre a barra de zero a fim de corrigir a leitura atual sobre ele. Quando a barra estiver fechando, o indicador deve enviar as informações finais sobre a barra para o servidor que devolverá o valor da barra fechada. Na desinicialização/ quebra da conexão, o servidor irá liberar o cabo alocado e destruirá o conjunto de dados (ou não, o que você preferir).
Variante nojenta - ao iniciar todo o sistema abranda com o terminal ou você tem que esperar muito tempo para carregar (alguns sistemas ainda estão usando canais lentos, por exemplo, naftalina). É muito melhor baixar as informações em pequenos pedaços e salvar o histórico na máquina do usuário para que apenas informações frescas sejam enviadas ao tráfego como é feito nas últimas versões: http: //xrust.land.ru/download/
Подкиньте идейку
O primeiro elemento da série é armazenado explicitamente. Depois diferenciamos as séries e utilizamos a codificação entropia.
Variante nojenta
Mesmo no caso de DLL, é desejável dar as informações em pedaços para que o consumidor não tenha que esperar ("PORQUÊ?"), e é bom no final :)
Mesmo no caso de DLL é desejável dar as informações em pedaços para que o consumidor não sofra uma longa espera ("Por quê?"), e é bonito no final :)
Antecedentes/carga sincrônica, como eu entendo que implica.É o que eu estou dizendo...