내 fastXML parser를 다른 라이브러리I와 개발하고 비교하면서 작업자 프로세스를 매우 쉽고 효과적으로 사용하기 위한 새로운 프로젝트를 발견했습니다.

Piscina은 node.js의 일부 개발자가 만듭니다. 그리고 그것은 저를 완전히 놀라게 했습니다.

또한: 최근에 동료와 논쟁을 벌였는데, 일부 작업은 자바스크립트가 아닌 golang으로 구현한 후 훨씬 빨라졌습니다. node.js를 사용하면 작업자와 IPC(프로세스 간 통신)를 훨씬 더 빠르게 사용할 수 있다고 말했습니다. 그러나 구현은 너무 복잡하고 당분간은 범위를 벗어났습니다.

이제 작업자 프로세스에서 기능을 구현하는 piscina와 함께 케이크 조각이 되었고 프로세스는 이제 JS에서 직접 빠르게 실행됩니다. 실제 제한은 CPU가 아니라 네트워킹에 있기 때문입니다.

피시나 사용

먼저 worker.js 파일이 필요합니다. 단일 함수를 내보냅니다. 별도의 스레드에서 실행하려는 것입니다.

const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));

module.exports = async ({ a, b } => {
  await sleep(100);
  return a + b;
});

물론 잠을 자지 않고 처리 작업을 수행하고 그 결과를 반환합니다. Piscina는 CPU의 더 나은 사용을 위해 만들어졌습니다. db 쿼리 및 API 호출과 같이 단일 node.js 프로세스가 동시에 처리할 수 있는 작업에서는 이 모듈이 필요하지 않습니다.

CPU 처리 작업에는 이미지 처리, 암호화 및 암호 해독 또는 데이터 구문 분석이 포함될 수 있습니다. 이 프로세스는 sync 또는 async 기능으로 구현할 수 있습니다.
결과는 기본 프로세스로 다시 반환되거나 클라우드에 업로드된다고 가정해 보겠습니다. 무엇이든 필요합니다.

기본 프로세스에서 작업자 모듈을 사용하려면 다음을 수행합니다.

const Piscina = require('piscina');

const workerPool = new Piscina({
  filename: __dirname + '/worker.js'
});

(async function() {
  const result = await workerPool.runTask({ a: 4, b: 6 });
  console.log(result);  // Prints 10
})();

이것은 기본적으로 그것입니다. 작업자 풀은 이름을 바꿀 수 있으며 .runTask는 express 또는 graphql의 API 처리기에서 호출할 수 있습니다. 인수는 단일 개체여야 합니다. 그러나 props와 dept는 얼마든지 가질 수 있습니다.

구성을 위해 더 많은 옵션을 Piscina 생성자에 전달할 수 있습니다. 그리고 옵션은 나를 실망시키지 않았습니다. 이를 통해 위협 수, 메모리를 절약하기 위한 풀링 동작, 작업자 메모리 제한 및 처리 시간을 선택할 수 있습니다. 실제로 내가 생각할 수 있는 모든 것, 라이브러리에서 다르게 수행할 수 있는 합리적인 구성이 있었습니다.

미래

이것이 node.js 애플리케이션의 프로세스와 성능을 향상시킬 수 있는 많은 옵션을 열어줄 것이라고 생각합니다.

그러나 txml xmp 파서의 경우 모듈을 통합하지 않기로 결정했습니다. 애플리케이션 개발자가 사용할 때 CPU를 많이 사용하는 데이터 처리가 메인 스레드에서 작업자로 이동할 수 있기 때문입니다.

piscina 어떻게 생각하세요? 당신이 그것을 사용할 수있는 아이디어가 있습니까?