.. _optimize: ============ Optimization ============ A crawl goes as fast as its slowest part allows. :ref:`Find out which part that is ` before changing any setting. :ref:`Broad crawls ` have their own set of recommended adjustments. .. _optimize-bottleneck: Finding the bottleneck ====================== The bottleneck depends on the spider: on the same machine, one crawl can be limited by its own parsing code and another by the target website. So measure the crawl that you want to optimize. :class:`~scrapy.extensions.logstats.LogStats` reports crawl speed every :setting:`LOGSTATS_INTERVAL` seconds: .. code-block:: text [scrapy.extensions.logstats] INFO: Crawled 1200 pages (at 60 pages/min), scraped 1150 items (at 58 items/min) A rate that stays flat as you raise :setting:`CONCURRENT_REQUESTS` means something else is the limit. Reading the engine status ------------------------- The :ref:`telnet console ` reports, through ``est()``, what every part of the engine is doing at a given moment: .. code-block:: text len(engine.downloader.active) : 16 len(engine._slot.scheduler.mqs) : 92 len(engine.scraper.slot.active) : 0 engine.scraper.slot.active_size : 0 engine.scraper.slot.needs_backout() : False Take a few readings at different points of the crawl: - ``len(engine.downloader.active)`` stays at :setting:`CONCURRENT_REQUESTS`: the downloader is the limit. You are waiting on the network or on the target website. See :ref:`optimize-concurrency`. - ``len(engine.downloader.active)`` stays below :setting:`CONCURRENT_REQUESTS` while the scheduler queues (``mqs``, ``dqs``) hold requests: something throttles those requests before they reach the downloader, usually :setting:`CONCURRENT_REQUESTS_PER_DOMAIN`, :setting:`DOWNLOAD_DELAY` or :ref:`AutoThrottle `. - Both the downloader and the scheduler queues stay near empty: your spider is not producing requests fast enough. A crawl that walks pagination one page at a time cannot use more concurrency than it creates. See :ref:`optimize-requests`. - ``needs_backout()`` is ``True``, or ``active_size`` approaches :setting:`SCRAPER_SLOT_MAX_ACTIVE_SIZE`: responses arrive faster than your callbacks and :ref:`item pipelines ` handle them. The bottleneck is your own code. - ``len(engine._slot.scheduler.mqs)`` grows without settling: the crawl discovers requests faster than it downloads them. This is what makes long crawls run out of memory. Reading resource usage ---------------------- CPU Scrapy runs in a single process, and everything except DNS resolution and code you explicitly move to a thread runs in a single thread. One CPU core is the ceiling; a process sitting at 100% of a core is CPU-bound no matter how many cores the machine has. Use a sampling profiler, such as py-spy_, to find out which code is spending that CPU. :ref:`Selectors ` and item pipelines are the usual answer. .. _py-spy: https://github.com/benfred/py-spy Memory The :ref:`memory usage extension ` records :stat:`memusage/startup` and :stat:`memusage/max`. A :stat:`memusage/max` far above :stat:`memusage/startup` is expected; what matters is whether it keeps growing for as long as the crawl runs. Growth that tracks ``len(engine._slot.scheduler.mqs)`` is a scheduling problem, covered in :ref:`optimize-memory`. Growth that does not is a :ref:`memory leak `. Network Compare :stat:`downloader/response_bytes` over the crawl time against your available bandwidth. Saturated bandwidth caps concurrency regardless of any setting. DNS resolution is separate: it runs on a thread pool of :setting:`REACTOR_THREADPOOL_MAXSIZE` threads, and results are cached (:setting:`DNSCACHE_ENABLED`, :setting:`DNSCACHE_SIZE`). It only becomes a limit of its own when there are many different domains to resolve, as in :ref:`broad crawls `, where it shows up as slow starts and DNS timeouts. Disk :ref:`Feed exports ` write to disk on most crawls, although item data is usually small enough for that not to matter. The ones to suspect are :class:`~scrapy.downloadermiddlewares.httpcache.HttpCacheMiddleware` and the :ref:`media pipelines `, which write whole responses, and :setting:`JOBDIR`, which writes every scheduled request. .. _optimize-concurrency: Sending more requests at a time =============================== :setting:`CONCURRENT_REQUESTS` caps how many requests are being downloaded at any given moment, :setting:`CONCURRENT_REQUESTS_PER_DOMAIN` caps how many of those may target the same domain, and :setting:`DOWNLOAD_DELAY` sets a minimum wait between two consecutive requests to the same domain. A project generated by :command:`startproject` gets one request per second per domain out of these. Raise them to crawl a single website faster, and see :ref:`broad-crawls-concurrency` to spread requests across many websites instead. The limit that matters, though, is the one the target website tolerates. Exceeding it gets you throttled, served errors or banned, all of which make the crawl slower than a lower concurrency would have been. To find that limit: - Read the :ref:`robots.txt ` file of the website. Scrapy does not act on its ``Crawl-delay`` and ``Request-rate`` directives, so when they are present, translate them into :setting:`DOWNLOAD_DELAY` and concurrency settings yourself. - Check the traffic that the website already gets, using a service like `SimilarWeb`_ or `Cloudflare Radar`_. A rate that is a rounding error next to what the website serves anyway is unlikely to be a problem for it. .. _SimilarWeb: https://www.similarweb.com/ .. _Cloudflare Radar: https://radar.cloudflare.com/ - Look for a documented way in. An API, a bulk export or a search endpoint is both faster for you and cheaper for the website than crawling its pages, and the terms of service may state a rate. - Crawl when the website is idle, in its own timezone, so that the capacity you take is capacity nobody else wanted. - Raise concurrency gradually and watch the website respond. :stat:`downloader/response_status_count/{status_code}` counts for 429, 503 or the ban page of the website, growing :stat:`retry/count`, or a :ref:`download latency ` that climbs as you push harder, all mean you have gone past the limit. .. _optimize-requests: Producing requests faster ========================= A spider that discovers its requests one response at a time keeps the downloader idle no matter how high you set :setting:`CONCURRENT_REQUESTS`. To put more requests in the scheduler earlier: - Request every page at once when you can work out how many there are, e.g. from a page count or from a result count and a page size in the first response, instead of following a link to the next page on every response. - Get URLs from a source that lists many of them at once, such as a sitemap or a search or export endpoint of the target website. For a crawl that needs nothing else, :class:`~scrapy.spiders.SitemapSpider` reads sitemaps for you. - Raise the :attr:`~scrapy.Request.priority` of pagination requests, so that they are downloaded before the requests that they compete with, and discover the rest of the crawl sooner. Each of these trades memory for speed: a request produced before the downloader can take it waits in the scheduler, or on disk if you set :setting:`JOBDIR`. Pushed far enough, they turn memory or disk into your new bottleneck, which is why :ref:`optimize-memory` recommends the reverse of the last point. .. _optimize-resources: Lowering resource usage ======================= .. _optimize-memory: Lowering memory usage --------------------- - Lower :setting:`SCRAPER_SLOT_MAX_ACTIVE_SIZE`. - Lower :setting:`DOWNLOAD_MAXSIZE`, which allows a single response to take up to 1 GiB of memory by default, multiplied by your concurrency. Set :setting:`DOWNLOAD_WARNSIZE` first to find out whether the website actually serves responses that big. - Lower the number of :ref:`scheduled requests ` held in memory: - Increase the :attr:`~scrapy.Request.priority` of requests whose :attr:`~scrapy.Request.callback` cannot yield additional requests. For example, the following spider uses a higher priority (1) for book requests than for pagination requests: .. code-block:: python from scrapy import Spider class BooksToScrapeComSpider(Spider): name = "books_toscrape_com" start_urls = [ "http://books.toscrape.com/catalogue/category/books/mystery_3/index.html" ] def parse(self, response): next_page_links = response.css(".next a") yield from response.follow_all(next_page_links) book_links = response.css("article a") yield from response.follow_all(book_links, callback=self.parse_book, priority=1) def parse_book(self, response): yield { "name": response.css("h1::text").get(), "price": response.css(".price_color::text").re_first("£(.*)"), "url": response.url, } .. note:: If the number of request-yielding, low-priority requests scheduled at any given time is lower than concurrency settings (:setting:`CONCURRENT_REQUESTS_PER_DOMAIN` or :setting:`CONCURRENT_REQUESTS`), as in the example above, this can slow down your crawl by turning those requests into a bottleneck. - If you have many :ref:`start requests `, consider :ref:`delaying their iteration `. - Set :setting:`JOBDIR` to offload all scheduled requests to disk. - Be on the lookout for :ref:`memory leaks `. Lowering network usage ---------------------- - Install brotli_ and zstandard_ to support brotli-compressed_ and zstd-compressed_ responses. .. _brotli-compressed: https://www.ietf.org/rfc/rfc7932.txt .. _brotli: https://pypi.org/project/Brotli/ .. _zstd-compressed: https://www.ietf.org/rfc/rfc8478.txt .. _zstandard: https://pypi.org/project/zstandard/ - Enable :class:`~scrapy.downloadermiddlewares.httpcache.HttpCacheMiddleware` while developing your spider, so that re-runs do not download the same responses again. Lowering CPU usage ------------------ - Set :setting:`LOG_LEVEL` to ``"INFO"`` or higher. - Restrict what you parse. A :ref:`selector ` over a smaller part of the response, or a single query whose result you reuse, beats repeated queries over the whole document. Other tips ---------- - Try :ref:`using the asyncio reactor ` with uvloop_ as :ref:`custom event loop `, i.e. setting :setting:`ASYNCIO_EVENT_LOOP` to ``"uvloop.Loop"``. .. _uvloop: https://github.com/MagicStack/uvloop Alternatively, try :ref:`switching to a non-asyncio reactor `. - Disable unused :ref:`components `. For example, set :setting:`COOKIES_ENABLED` to ``False`` unless you need cookies. - Split the crawl across separate processes to use more than one CPU core. See :ref:`distributed-crawls`. .. _broad-crawls: .. _topics-broad-crawls: Speeding up broad crawls ======================== While Scrapy is well suited for **broad crawls**, i.e. crawls that target many websites, the default :ref:`settings ` are optimized for crawls targeting a single website. For broad crawls, consider these adjustments: - .. _broad-crawls-concurrency: Increase the global concurrency: - Set :setting:`CONCURRENT_REQUESTS` as close to :setting:`CONCURRENT_REQUESTS_PER_DOMAIN` × [number of target domains] (e.g. 8 × 10 domains = 80 concurrent requests) as your CPU and memory allow. - Increase :setting:`SCRAPER_SLOT_MAX_ACTIVE_SIZE` when increasing :setting:`CONCURRENT_REQUESTS` stops making a difference. - .. _broad-crawls-bfo: If memory is a bottleneck, see if :ref:`crawling in BFO order ` lowers memory usage. - Improve DNS resolution speed: - Set up your own DNS server, with a local cache and upstream to a `large DNS server`_, to avoid slowing down your network. .. _large DNS server: https://en.wikipedia.org/wiki/Public_recursive_name_server#Notable_public_DNS_service_operators - Increase :setting:`REACTOR_THREADPOOL_MAXSIZE` to the minimum value that avoids DNS resolution timeouts and makes a noticeable positive impact in crawl speed. - Lower the negative impact of some responses: - Set :setting:`RETRY_ENABLED` to ``False`` or, if you need retries, consider lowering :setting:`RETRY_TIMES`. - Lower :setting:`DOWNLOAD_TIMEOUT` to a more reasonable value, to discard stuck requests more quickly. - Set :setting:`REDIRECT_ENABLED` to ``False`` unless you want to follow redirects.