저는 Ruby/Rails 웹 애플리케이션을 가지고 있으며 작업 중 하나는 애플리케이션에서 생성된 PDF 파일을 네트워크의 Xerox 4127 프린터로 보내는 것입니다. 이는 여러 lpr 명령을 종료하고 실행하여 수행됩니다(기본 인쇄 대기열, 스풀링 복사본을 방지하려면 -s 사용, 트레이 식별을 위해 -o InputSlot 사용). PDF는 파일 세부 사항 및 필요한 용지 색상에 따라 다른 트레이로 전송되므로 하나의 문서/인쇄 작업으로 결합할 수 없습니다. "주기"에는 15,000개 이상의 페이지가 포함될 수 있으며, 한 번에 20~30~100개의 일괄 처리로 프린터에 전송됩니다.
저는 일반 PCL 6 Gutenprint 드라이버를 사용하여 서버의 프린터를 LPD 대기열로 설정했습니다. Xerox는 Linux 드라이버를 제공하지 않지만 lpd/lpr과 함께 작동할 것이라고 말합니다. 실제로 명령줄에서든 웹 애플리케이션을 통해 수동으로 문서를 성공적으로 보낼 수 있었습니다.
이 프로세스는 Foxpro에서 Windows 프로그램으로 프로토타입화되었습니다. 프로토타입은 배치의 각 페이지에 대해 PDF를 생성하고 이를 별도의 인쇄 작업으로 보냅니다. 프린터에 미터법 메모리 버튼이 있기 때문에 프로토타입은 작업을 하나씩 프린터에 덤프하고 프린터가 모든 작업을 관리할 수 있도록 하며 훌륭한 작업을 수행합니다. 수백 페이지/인쇄 작업 묶음이 거의 즉시 프린터 대기열에 추가되고, 프린터는 마치 하나의 거대한 문서의 일부인 것처럼 거의 멈추지 않고 해당 작업을 내보냅니다.
내 웹 응용 프로그램은 실제로 동일한 트레이에 전송된 페이지를 차례로 PDF로 결합하므로 실제로는 속도가 더 빨라질 것으로 예상했지만 그렇지 않습니다. 이 프로세스는 훨씬 더 느립니다. 프로토타입에서 실행하는 데 8시간이 걸린 "사이클"이 웹 애플리케이션에서 완료되는 데 며칠이 걸립니다.
무슨 일이 일어나고 있는 것 같으면 프로토타입에서처럼 인쇄 작업이 프린터에 "덤프"되지 않는다는 것입니다. 화면 유틸리티를 통해 프린터를 모니터링하면 한 번에 하나의 인쇄 작업만 볼 수 있습니다. 서버의 인쇄 대기열은 프린터가 이전 작업이 완료되었다는 신호를 반환할 때까지 각 인쇄 작업을 보내기 위해 기다리고 있는 것으로 보입니다. 그래서 문서처럼 끊임없이 모든 것을 뱉어내는 대신 한 페이지를 얻은 다음 다음 파일이 들어오면 일시 중지하고 몇 페이지, 다음 페이지, 일시 중지 등을 수행합니다.... . 이해했다.
서버의 인쇄 대기열이 실제로 프린터가 "완료"라고 말할 때까지 기다리고 있습니까? 그렇다면 프린터에서 통신이 돌아올 때까지 기다리지 않고 보내기, 보내기, 보내기만 하도록 구성할 수 있습니까?
두 가지 참고 사항: 서버는 다른 건물에 있지만 프린터와 정확히 동일한 서브넷에 있는 컴퓨터에서 일부 테스트를 수행했지만 측정 가능한 개선 사항은 발견되지 않았습니다. 즉, 네트워크와 관련이 없는 것 같습니다. 다시 말하지만, lpr이 PDF 문서를 보내기 전에 포스트스크립트로 변환한다는 것을 알고 있으므로 미리 변환하고 변환 없이 프로세스를 테스트했습니다. 서버의 대기열 프로세스가 개선되었는데, 이는 특별히 극적이지는 않지만 한 번에 하나의 작업만 프린터로 전송된다는 사실에 아무런 영향을 미치지 않았으며 이것이 근본적인 문제라고 생각합니다.