Tedious: 다른 쿼리를 지연시키는 StreamParser

에 만든 2015년 10월 04일 · 11코멘트 · 출처: tediousjs/tedious

node-mssql에 문제가 있습니다. "node-mssql은 쿼리에서 실제로 동시 실행되지 않습니다."
문제: https://github.com/patriksimek/node-mssql/issues/217

짧은 설명: 지루한 스트림 파서가 다른 스트리밍 쿼리가 처리되는 것을 _might_ 차단하기 때문에 스트림이 활성화된 여러 쿼리가 동시에 실행되지 않습니다.

  StreamParser.prototype._transform = function (input, encoding, done) {
    var job, length, offset, result;
    offset = 0;
    this.buffer.append(input);
    if (!this.generator) {
      this.generator = this.parser();
      this.currentStep = this.generator.next();
    }
    job = void 0;
    result = void 0;
    length = void 0;
    while (!this.currentStep.done) {
      job = this.currentStep.value;
      if (!(job instanceof Job)) {
        return done(new Error('invalid job type'));
      }
      length = job.length;
      if (this.buffer.length - offset < length) {
        break;
      }
      result = job.execute(this.buffer, offset);
      offset += length;
      this.currentStep = this.generator.next(result);
    }
    this.buffer.consume(offset);
    if (this.currentStep.done) {
      this.push(null);
    }
    return done();
  };

Visual Studio Code로 프로그램을 디버깅하고 있는데 스트림 파서 내부의 while 루프 히트가 다른 쿼리가 처리되거나 행을 반환하지 못하도록 차단하는 것 같습니다.

여러 동시 연결이 열려 있을 때 StreamParser가 처리되는 방법에 대해 알려주실 수 있습니까?

@arthurschreiber
@patriksimek

Action Required Response needed known issue

출처

luca-moser

가장 유용한 댓글

또한 이 문제는 대용량 데이터로 작업하는 확장성 비즈니스 응용 프로그램을 작성하는 데 있어 시장을 방해하는 요소이기 때문에 이 주제에 대해 진행 상황이 있는지 알고 싶습니다.

query()가 모든 요청을 차단하기 때문에 전체 앱이 새로운 요청을 수락할 수 없으면 사용자 경험이 더 나빠집니다.

여기에 진전이 있다면 정말 감사하겠습니다.

문안 인사,
남자 이름

Mika83AC 에 2017년 06월 16일

👍6

모든 11 댓글

안녕하세요 @XemsDoom

귀하의 문제 설명을 읽었으며 귀하의 문제가 tedious 작동 방식에 있는지 아니면 일반적으로 Node.JS에 있는지 궁금합니다. Node.js는 단일 스레드 이벤트 기반 환경이므로 CPU에서 발생하는 모든 종류의 처리는 항상 다른 CPU 처리 작업을 차단합니다.

tedious 의 스트림 구문 분석 코드와 관련하여: 들어오는 데이터의 구문 분석은 "비동기적으로 동기"입니다. 이것은 스트림 파서에 (비동기적으로) 푸시된 데이터가 동기적으로 파싱된다는 것을 의미합니다. 따라서 스트림에서 데이터를 사용할 수 있는 한 해당 데이터는 구문 분석되며 이는 차단 동기 작업입니다.

나는 구문 분석을 "비동기식으로 비동기식"으로 만드는 작업을 해왔지만 tedious 의 기존 내부는 기존 동작에 따라 달라지며 변경해야 합니다.

이전 버전의 지루한(예: 1.11.5 )을 사용해 보고 문제가 이미 존재하는지 확인할 수 있습니다. 이 문제를 해결하는 것은 분명히 내 목록에 있지만 지금 당장은 그다지 우선 순위가 높지 않습니다.

arthurschreiber 에 2015년 10월 04일

구텐 아벤드 @arthurschreiber. 나는 NodeJS가 어떻게 작동하는지 알고 있고 CPU 집약적인 JS 코드는 모든 것이 단일 스레드에서 실행되기 때문에 다른 모든 처리를 차단할 것입니다.

제 생각에는 지루하거나 잘못된 디자인 결정에 버그가 있습니다. 왜냐하면 지금처럼 작동하지 않아야 한다고 확신하기 때문입니다. 여러 스트리밍 쿼리를 순차적으로 처리하면 안 됩니다. "순차적으로"란 이전 쿼리가 완료된 후 처리되는 쿼리를 의미합니다.

하나의 쿼리에 많은 행이 있는 경우(예: 100k 및 두 번째 쿼리 50k 행), 데이터베이스 서버에서 행을 가져올 때 쿼리가 얽혀 있는 스트림 파서에 의해 처리되어야 합니다.

왜요? 다른 웹 요청이 두 개의 다른 테이블에서 데이터를 검색하려는 경우 다른 데이터베이스 쿼리로 인해 한 사용자가 기다리는 것을 원하지 않기 때문입니다. 우리는 이 디자인을 사용하는 기존 웹 서버와 동일한 딜레마를 겪고 있습니다.

독일어로 설명하려고 하니 이해가 더 쉬울 것 같아요 :)

지루한 Bearbeitet nur eine Query zu einem gegebenen Zeitpunkt, statt alle ausgeführten Queries gemeinsam _nebenläufig_ im Stream Parser zu bearbeiten, momentan werden die anderen Queries nicht bearbeitet also Query bisd die ersteerste bzw. Werden diese somit sequenziell abgearbeitet.

Ergo, führst du 3 Queries aus und hast 3 Callbacks für wenn Rows gefetcht wurden, werden die 2 weiteren 콜백 erst aufgerufen, wenn die erste Query durch ist, obwohl eigentlich durch das Streaming dievers Mit _Miteinander_ meine ich, dass alle 3 Callbacks jeweils in einer offensichtlich nicht geordneten Abfolge gerufen werden.

또한 zum Beispiel은 다음과 같습니다.
쿼리 1, 쿼리 2, 쿼리 3 werden nebenläufig ausgeführt. mssql의 연결 풀에서 고유한 연결을 쿼리하십시오.

Nun sollten die Rows von allen 3 Queries eigentlich gleichzeitig zurück kommen:
행 쿼리1, 행 쿼리1, 행 쿼리3, 행 쿼리2, 행 쿼리3, 행 쿼리2, 행 쿼리2....
결정 사항은 결정 사항에 따라 결정됩니다.

지루한 aber führt das ganze so aus:
row-query1, row-query1, row-query1.....bis stop fertig....dann row-query2, row-query2, row-query2....bis wieder fertig....dann row-query3 , 행 쿼리3, 행 쿼리3....

너무 행복했습니다. dass hat ja nichts damit zu tun, dass NodeJS single-threaded ist, sondern dass der Parser nicht verschiedene Queries _konkurrierend_ bearbeitet.

luca-moser 에 2015년 10월 04일

안녕하세요 @XemsDoom

자세한 설명(및 독일어 번역 - 다른 사람들이 우리가 말하는 내용을 이해할 수 있도록 영어로 답변하겠습니다)에 감사드립니다. :웃다:

위에서 설명했듯이 이것은 현재 지루한 것으로 알려져 있지만 문서화되지 않은 제한 사항이며 1.12 릴리스 라인과 생성기로의 전환에서 도입한 불행한 성능 문제를 수정한 후 이를 수정하기 위해 작업할 계획입니다.

나는 파싱이 얽혀 있도록 변경하는 로컬 분기를 가지고 있지만 현재 하나의 이벤트 루프 턴에서 특정 순서로 발생하는 이벤트에 의존하는 다른 지루한 내부를 깨뜨립니다. 이 모든 것은 고칠 수 있지만 1.12 릴리스에서 했던 것과 같은 실수를 하고 싶지 않기 때문에 시간과 철저한 테스트가 필요합니다.

이 문제를 해결하기 위해 자유롭게 노력하라고 말하고 싶지만 성능 향상을 위한 향후 변경 사항은 토큰 구문 분석 코드를 많이 변경할 것이며 시간을 낭비하고 싶지 않습니다. :실망한_안심:

arthurschreiber 에 2015년 10월 04일

고마워 아서. 당신은 이미 이 문제를 알고 있는 것 같으며 당신이 그것에 대해 노력하고 있다는 것에 감사합니다. 문제가 언제 수정되었는지 확인할 수 있도록 이 문제를 공개할 수 있습니까? 어떤 식으로든 도움이 될 수 있다면 말씀해 주세요. 기꺼이 도와드리겠습니다.

좋은 저녁 되세요.

luca-moser 에 2015년 10월 04일

@arthurschreiber 이 작업을 수행하고 있습니까? "작업 중"이라고 마지막으로 보고된 지 1년 반이 지났습니다.

Shockolate 에 2017년 06월 14일

👍3

query()가 모든 요청을 차단하기 때문에 전체 앱이 새로운 요청을 수락할 수 없으면 사용자 경험이 더 나빠집니다.

여기에 진전이 있다면 정말 감사하겠습니다.

문안 인사,
남자 이름

Mika83AC 에 2017년 06월 16일

👍6

안녕하세요 @arthurschreiber ,

스트림이 완료될 때까지 스트림이 전체 nodeJS 앱을 차단하는 것과 동일한(제 생각에는?) 문제가 발생하고 있지만 @luca-moser가 앞서 인용한 대로 영향을 받는 코드 블록을 찾는 데 어려움을 겪고 있습니다. 내 특정 사용 사례에 맞게 수정할 수 있는지 확인하고 싶으므로 올바른 방향으로 저를 가리켜 주시겠습니까? 비동기식 비동기 솔루션을 테스트하는 로컬 분기가 있다고 언급했습니다. 이 문제와 이로 인해 발생하는 알려진 문제를 공유할 수 있습니까? 감사 해요!

Blakey 에 2017년 09월 18일

여보세요. 나도 곤란해. 나는 스트림을 사용하여 많은 양의 데이터를 얻고 웹 소켓을 사용하여 프런트 엔드에서 보냅니다. 모두 잘 작동하지만 스트리밍하는 동안 지루한 것이 여전히 차단됩니다. 소식이 있나요? non-blocking 방식으로 사용할 수 있습니까?

감사 해요

spimou 에 2019년 12월 17일

5년 반이 지났지만 스트림의 비동기 동기 동작은 여전히 수정되지 않았습니다. :-(

bluefire2121 에 2021년 02월 23일

@bluefire2121 https://github.com/tediousjs/tedious/pull/1240 이 문제를 해결할 것이라고 생각합니다. 5년 반 후. 😬

arthurschreiber 에 2021년 03월 17일

방금 [email protected] 를 tedious@next 릴리스 채널에 릴리스했습니다. 여기에서 설명하는 문제가 해결되면 답변을 드리겠습니다.

문제가 발생하지 않으면 일주일 후에 자동으로 tedious@latest 릴리스 채널로 승격됩니다.

arthurschreiber 에 2021년 03월 25일

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Tedious: 다른 쿼리를 지연시키는 StreamParser

가장 유용한 댓글

모든 11 댓글

관련 문제