Support for Multiple IO Threads?

[geoffrey]

Hello,

I am trying to increase the number of IO threads to remove a bottleneck in my libcef-based application but have so far been unsuccessful.

My first attempt simply created 3 new CefIOThread objects (CefThread:IO2, CefThread:IO3, and CefThread:IO3) with the goal of dispatching requests to them in a round-robin fashion. Naturally, this doesn't work because other places in libcef were designed with a single IO thread in mind. Fortunately LIBCEF has lots of assertions that let me quickly discover that this change broke core assumptions.

I am now looking for alternative strategies. Would this work: In CefUrlRequestJob::Start (scheme_impl.cc), instead of posting the AsyncResolver::Resolve method to IO thread, post it to one of a set of [newly] CefResolverThreads. This would seem to have the effect of allowing multiple Request jobs to happen while maintaining the single IO thread for all other IO-thread activities. Is this a practical solution or dispatching requests in this way cause other problems because items further in the queue depend upon items earlier completing serially?

Is there a better way? Is there no way?

Warm Regards,
Geoffrey

[geoffrey]

Quick follow-up. I have implemented the method described in my post (in scheme_impl.cc) and it appears to work properly with one caveat. The following DCHECK fails in polling_proxy_config_service.cc:

Code: Select all

//DCHECK(origin_loop_proxy_->BelongsToCurrentThread());


With this DCHECK disabled (probably not ideal) everything seems to work properly.

I've attached a .zip file that contains my changes to LIBCEF for your feedback.

Warm Regards,
- Geoffrey

[magreenblatt]

Do you have any numbers on the improvement in performance using 4 IO threads instead of 1? Also, I wonder if this approach could be helpful in the general resource loading case (browser_resource_loader_bridge.cc) or if the serialization in WebKit would make it a moot point.

[geoffrey]

Hi,

I haven't done deep analysis, yet, but I am seeing an improvement of between 35% and 60% getting the page loaded when loading content from my custom scheme handler. That scheme handler loads content from a .ZIP file, the filesystem, or a generates content dynamically depending on the request. HTTP content, subject to the finicky nature of the network, is loading 100-200% when measuring the total time to load the page.

Warm Regards,
Geoffrey