사실 전문가는 정보를 얻기 위해 1초 이상 걸을 수 없습니다. 이것이 MT4 <-> wininet.dll <-> 서버 번들이 작동하는 방식입니다.
글쎄, 클라이언트는 매초 요청으로 서버를 망치게 될 것입니다. 그래서 무엇? 그것이 그가 어떤 부하도 견딜 수 있는 서버인 이유입니다. Google이 어떻게 망치고 있는지 또는 VKontakte를 상상해보십시오.
이 요청-응답 번들에서 각각 3개의 터미널을 실행하는 20대의 머신과 테스터에서 실행할 때의 요청에서 검증을 테스트했습니다!
그리고 실험에 참가한 모든 참가자는 매우 시원하다고 느꼈습니다(제공자도 마찬가지입니다:). 유일한 것은 테스트가 느리다는 것입니다. 틱은 초당 한 번 처리됩니다. 하지만 그것도 그렇게 큰 문제는 아니다.
따라서 이러한 시스템(특정 코드 블록이 인터넷에 게시됨)은 꽤 작동합니다.
그리고 이러한 번들에서 테스트가 정상적으로 작동하도록 하기 위해 파일 이름에 타임스탬프가 있는 별도의 파일에 데이터를 덤프하기만 하면 됩니다. 결과적으로 첫 번째 실행 후 테스터는 디렉토리의 모든 데이터를 추가합니다. 두 번째 실행은 이미 이 데이터가 로컬 시스템의 데이터베이스에 있는 경우보다 훨씬 빠르게 실행됩니다. 실제 파일은 상당히 많을 수 있습니다.
그리고 이러한 번들에서 테스트가 정상적으로 작동하도록 하기 위해 파일 이름에 타임스탬프가 있는 별도의 파일에 데이터를 덤프하기만 하면 됩니다. 결과적으로 첫 번째 실행 후 테스터는 디렉토리의 모든 데이터를 추가합니다. 두 번째 실행은 이미 이 데이터가 로컬 시스템의 데이터베이스에 있는 경우보다 훨씬 빠르게 실행됩니다. 실제 파일은 상당히 많을 수 있습니다.
원칙적으로 옵션으로 ... 이것은 한 번에 모든 데이터를 수신하거나 약간 또는 자주 수신하는 것 사이의 교차입니다.
sergeev писал(а)>> 예를 들어 표시기의 한 줄에 대해 250,000바 * 8바이트(막대 시간) + 8바이트(줄 값) ~ 4MB 정보.
1. 모든 지표에 시간이 필요한 것은 아닙니다. 2. 따옴표를 압축할 수 있습니다. 시간도 압축 가능 3. 매번 모든 견적을 전송할 필요는 없습니다. 더 경제적 인 옵션이 있습니다. 초기화하는 동안 표시기는 서버에 로그인하여 많은 양의 데이터를 전송합니다. 서버는 수신된 데이터 세트 및 이 데이터를 보낸 클라이언트와 관련된 일부 핸들을 반환합니다. 작동 중에 표시기는 현재 판독 값을 수정하기 위해 제로 바 표시기에 대한 정보를 주기적으로 보냅니다. 막대를 닫는 동안 표시기는 막대에 대한 최종 정보를 서버로 보내야 하며 서버는 닫힌 막대의 값을 반환합니다. 연결을 초기화/해제할 때 서버는 할당된 핸들을 해제하고 데이터 세트를 파괴합니다(또는 원하는 대로 해제하지 않음). 4. 또한 표시기는 클라이언트 측에서 수신된 표시기 값을 캐시할 수 있습니다(계산된 압축 데이터 블록과 함께 저장할 수 있음). UPD: 일반적으로 모든 틱에 대한 지표를 다시 계산하는 것은 불가능합니다. 매우 자주 틱은 +1 -1 +1 -1 +1 -1과 같이 흐릅니다. 실제로 지표를 2번만 계산하면 됩니다.
3. 매번 모든 견적을 전송할 필요는 없습니다. 더 경제적 인 옵션이 있습니다. 초기화하는 동안 표시기는 서버에 로그인하여 많은 양의 데이터를 전송합니다. 서버는 수신된 데이터 세트 및 이 데이터를 보낸 클라이언트와 관련된 일부 핸들을 반환합니다. 작동 중에 표시기는 현재 판독 값을 수정하기 위해 제로 바 표시기에 대한 정보를 주기적으로 보냅니다. 막대를 닫는 동안 표시기는 막대에 대한 최종 정보를 서버로 보내야 하며 서버는 닫힌 막대의 값을 반환합니다. 연결을 초기화/해제할 때 서버는 할당된 핸들을 해제하고 데이터 세트를 파괴합니다(또는 원하는 대로 해제하지 않음).
이것은 칠면조 계통에 대한 데이터 전송 속도를 높일 수 있는 방법이 약간 불분명합니다.
4. 또한 표시기는 클라이언트 측에서 수신된 표시기 값을 캐시할 수 있습니다(계산된 압축 데이터 블록과 함께 저장할 수 있음). 유추하여 이미 MT - IndicatorCounted()에 구현되어 있습니다. 나는 그러한 목적을 위해 내 자신의 유사한 기능을 작성할 것입니다. UPD: 일반적으로 모든 틱에 대한 지표를 다시 계산하는 것은 불가능합니다. 매우 자주 틱은 +1 -1 +1 -1 +1 -1과 같이 흐릅니다. 실제로 지표를 2번만 계산하면 됩니다.
즉, 칠면조의 경우 이제 문제를 해결하기 시작했습니다. 메타쿼타는 아주 오래 전에 결정되었습니다. 히스토리 바 동기화 및 전송 :) 그들이 집에서 그러한 서비스를 할 수 있도록 제안을 해야 할 수도 있습니다! 흥미로운 생각이네요. 시가/종가/하이/로우가 동일한 그러한 상품을 서버에 저장하도록 하십시오. 그리고 볼륨도요. 모든 통화와 마찬가지로 모든 일반 규칙에 따라 로드되고 동기화됩니다. 그런 다음 인듀서 라인으로 사용할 수 있습니다.
다소 비뚤어진 해결책도 있습니다. 1) 지표가 있는 차트의 스크린샷을 찍습니다. 2) 스크린샷 파일을 HTTP 서버에 업로드 3) 사용자는 자신의 로그인/비밀번호로 로그인하고 사진을 봅니다. 진실은 칠면조를 볼 필요가있는 경우에만 적합합니다. 스스로 구축할 다른 것이 있다면 ... :(
lea писал(а)>> 3. 매번 모든 견적을 전송할 필요는 없습니다. 더 경제적 인 옵션이 있습니다. 초기화하는 동안 표시기는 서버에 로그인하여 많은 양의 데이터를 전송합니다. 서버는 수신된 데이터 세트 및 이 데이터를 보낸 클라이언트와 관련된 일부 핸들을 반환합니다. 작동 중에 표시기는 현재 판독 값을 수정하기 위해 제로 바 표시기에 대한 정보를 주기적으로 보냅니다. 막대를 닫는 동안 표시기는 막대에 대한 최종 정보를 서버로 보내야 하며 서버는 닫힌 막대의 값을 반환합니다. 연결을 초기화/해제할 때 서버는 할당된 핸들을 해제하고 데이터 세트를 파괴합니다(또는 원하는 대로 해제하지 않음).
역겨운 옵션 - 시작 시 전체 시스템이 터미널과 함께 느려지거나 로딩을 위해 매우 오랜 시간을 기다려야 합니다(일부는 여전히 느린 채널에 있습니다(예: mophil 네트워크)). 정보를 작은 조각으로 다운로드하는 것이 훨씬 더 편리하며 사용자 컴퓨터의 기록을 유지하므로 최신 버전에서 결정된 대로 최신 정보만 트래픽에 들어갑니다. http://xrust.land.ru/download/
그리고 준수해서는 안됩니다.
사실 전문가는 정보를 얻기 위해 1초 이상 걸을 수 없습니다. 이것이 MT4 <-> wininet.dll <-> 서버 번들이 작동하는 방식입니다.
글쎄, 클라이언트는 매초 요청으로 서버를 망치게 될 것입니다. 그래서 무엇? 그것이 그가 어떤 부하도 견딜 수 있는 서버인 이유입니다. Google이 어떻게 망치고 있는지 또는 VKontakte를 상상해보십시오.
이 요청-응답 번들에서 각각 3개의 터미널을 실행하는 20대의 머신과 테스터에서 실행할 때의 요청에서 검증을 테스트했습니다!
그리고 실험에 참가한 모든 참가자는 매우 시원하다고 느꼈습니다(제공자도 마찬가지입니다:). 유일한 것은 테스트가 느리다는 것입니다. 틱은 초당 한 번 처리됩니다. 하지만 그것도 그렇게 큰 문제는 아니다.
따라서 이러한 시스템(특정 코드 블록이 인터넷에 게시됨)은 꽤 작동합니다.
그리고 이러한 번들에서 테스트가 정상적으로 작동하도록 하기 위해 파일 이름에 타임스탬프가 있는 별도의 파일에 데이터를 덤프하기만 하면 됩니다. 결과적으로 첫 번째 실행 후 테스터는 디렉토리의 모든 데이터를 추가합니다. 두 번째 실행은 이미 이 데이터가 로컬 시스템의 데이터베이스에 있는 경우보다 훨씬 빠르게 실행됩니다. 실제 파일은 상당히 많을 수 있습니다.
그리고 이러한 번들에서 테스트가 정상적으로 작동하도록 하기 위해 파일 이름에 타임스탬프가 있는 별도의 파일에 데이터를 덤프하기만 하면 됩니다. 결과적으로 첫 번째 실행 후 테스터는 디렉토리의 모든 데이터를 추가합니다. 두 번째 실행은 이미 이 데이터가 로컬 시스템의 데이터베이스에 있는 경우보다 훨씬 빠르게 실행됩니다. 실제 파일은 상당히 많을 수 있습니다.
원칙적으로 옵션으로 ... 이것은 한 번에 모든 데이터를 수신하거나 약간 또는 자주 수신하는 것 사이의 교차입니다.
가장 중요한 것은 작업이 정확할수록 속도 측면에서 최적화할 기회가 더 많다는 것입니다.
예를 들어 표시기의 한 줄에 대해 250,000바 * 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과 같이 흐릅니다. 실제로 지표를 2번만 계산하면 됩니다.
즉, 칠면조의 경우 이제 문제를 해결하기 시작했습니다. 메타쿼타는 아주 오래 전에 결정되었습니다. 히스토리 바 동기화 및 전송 :)
그들이 집에서 그러한 서비스를 할 수 있도록 제안을 해야 할 수도 있습니다!
흥미로운 생각이네요. 시가/종가/하이/로우가 동일한 그러한 상품을 서버에 저장하도록 하십시오. 그리고 볼륨도요. 모든 통화와 마찬가지로 모든 일반 규칙에 따라 로드되고 동기화됩니다. 그런 다음 인듀서 라인으로 사용할 수 있습니다.
막대 동기화에 대한 기술 문서에서 이 방향으로 파고들 가치가 있을 것입니다.
1) 지표가 있는 차트의 스크린샷을 찍습니다.
2) 스크린샷 파일을 HTTP 서버에 업로드
3) 사용자는 자신의 로그인/비밀번호로 로그인하고 사진을 봅니다.
진실은 칠면조를 볼 필요가있는 경우에만 적합합니다. 스스로 구축할 다른 것이 있다면 ... :(
3. 매번 모든 견적을 전송할 필요는 없습니다. 더 경제적 인 옵션이 있습니다. 초기화하는 동안 표시기는 서버에 로그인하여 많은 양의 데이터를 전송합니다. 서버는 수신된 데이터 세트 및 이 데이터를 보낸 클라이언트와 관련된 일부 핸들을 반환합니다. 작동 중에 표시기는 현재 판독 값을 수정하기 위해 제로 바 표시기에 대한 정보를 주기적으로 보냅니다. 막대를 닫는 동안 표시기는 막대에 대한 최종 정보를 서버로 보내야 하며 서버는 닫힌 막대의 값을 반환합니다. 연결을 초기화/해제할 때 서버는 할당된 핸들을 해제하고 데이터 세트를 파괴합니다(또는 원하는 대로 해제하지 않음).
역겨운 옵션 - 시작 시 전체 시스템이 터미널과 함께 느려지거나 로딩을 위해 매우 오랜 시간을 기다려야 합니다(일부는 여전히 느린 채널에 있습니다(예: mophil 네트워크)). 정보를 작은 조각으로 다운로드하는 것이 훨씬 더 편리하며 사용자 컴퓨터의 기록을 유지하므로 최신 버전에서 결정된 대로 최신 정보만 트래픽에 들어갑니다. http://xrust.land.ru/download/
Подкиньте идейку
시리즈의 첫 번째 요소는 명시적으로 저장됩니다. 다음으로 계열을 구별하고 엔트로피 코딩을 사용합니다.
역겨운 옵션
DLL의 경우에도 정보를 쪼개서 제공하는 것이 바람직하고 소비자가 기대에 게으르지 않고 ("왜?"라는 어리석은 질문을하지 않음) 결국 아름답습니다 :)
DLL의 경우에도 정보를 쪼개서 제공하는 것이 바람직하고 소비자가 기대에 게으르지 않고 ("왜?"라는 어리석은 질문을하지 않음) 결국 아름답습니다 :)
내 이해에서 백그라운드/비동기 로딩은 이것을 의미합니다.그게 내 얘기야...