이제 Windows 환경에서는 멀티스레드 크롤링을 사용합니다.
구문 분석에는 beautifulsoup+lxml을 사용합니다.
N 크롤링 스레드->파싱 큐->파싱 스레드 1개->저장 큐->저장 스레드 1개
전체 실행 프로그램의 효율성은 계산 집약적인 구문 분석 스레드에 갇혀 있습니다. 구문 분석 스레드 수만 늘리면 스레드 전환 오버헤드가 증가하고 속도가 느려집니다.
죄송합니다. 구문 분석 효율성을 크게 향상시킬 수 있는 방법이 있나요?
두 허벅지의 지시에 따라
비동기 크롤링->파싱 큐->N 파싱 프로세스->스토리지 큐->스토리지 스레드
공사 시작 준비
为情所困2017-06-12 09:22:36
사실 님이 먼저 다시 작성하신 것 같은데N个爬取线程 可以换成协程/线程池实现, 因为你在频繁创建线程本省一种性能耗费, 用线程池虽然可以减少这部分的损耗, 但是上下文切换还是无法避免, 所以协程这方面, 应该是比较合适的.1个解析线程 换成 进程池,多开几个进程去计算密集处理, 其余应该可以不用改, 如果还想再搞, 将核心部分用c/c++ 도움이 되셨으면 좋겠습니다
怪我咯2017-06-12 09:22:36
내 접근 방식은 다중 프로세스입니다. 다중 프로세스의 장점은 단일 머신의 성능이 충분하지 않을 때 언제든지 분산 크롤러로 전환할 수 있다는 것입니다.