Bug 137367 – [Mac] We are spending too much time serializing ProtectionSpace objects

• Component: Page Loading
• Status: RESOLVED FIXED

[Chris Dumez]

When profiling the load of nytimes.com, I noticed that we were spending a lot of cpu time serializing ProtectionSpace objects (in particular the NSURLProtectionSpace platform data):
- 5.6% of CPU time for Network Process
- 2.5% of CPU time for WebProcess

Serializing an NSURLProtectionSpace seems to be costly due to server trust verification. We do this for every sub-resource load over HTTPS due to the canAuthenticateAgainstProtectionSpace() callback for server trust validation, from the NetworkProcess to the WebProcess and then to the UIProcess:

After discussing with Dan, a possibility for the short-term would be to add a "LetPlatformHandleServerTrustValidation" setting so that we can let CFNetwork handle the server trust validation (this is what ends up happening anyway currently), to avoid doing all the IPC (and thus serialization) unnecessarily for server trust validation, if the client does not handle it.

[Chris Dumez]

I was thinking "setShouldHandleHTTPSServerTrustEvaluationAtNetworkLevel(bool)" for the (private) setting. Any thoughts?

[Chris Dumez]

Created attachment 239158 [details]
WIP Patch

[Chris Dumez]

<rdar://problem/18516890>

[Chris Dumez]

Created attachment 239159 [details]
WIP Patch

[Chris Dumez]

Created attachment 239210 [details]
Patch

Just a couple of comments:
1. If a Networking process crashes and the WebContext launches a new one to replace it, it will lose this state. To fix this, the WebContext needs to keep the flag and include it in the initialization parameters to the Networking process.
2. This should also be exposed as WKProcessPool SPI so that it can be used by clients of that API.

[Chris Dumez]

(In reply to comment #6)
> Just a couple of comments:
> 1. If a Networking process crashes and the WebContext launches a new one to replace it, it will lose this state. To fix this, the WebContext needs to keep the flag and include it in the initialization parameters to the Networking process.
> 2. This should also be exposed as WKProcessPool SPI so that it can be used by clients of that API.

Thanks for the feedback, this is very helpful. I will address these issues soon.

[Chris Dumez]

Created attachment 239218 [details]
Patch

[Chris Dumez]

(In reply to comment #6)
> Just a couple of comments:
> 1. If a Networking process crashes and the WebContext launches a new one to replace it, it will lose this state. To fix this, the WebContext needs to keep the flag and include it in the initialization parameters to the Networking process.
> 2. This should also be exposed as WKProcessPool SPI so that it can be used by clients of that API.

All done in the latest patch iteration, thanks.

[Chris Dumez]

Ping review?

Comment on attachment 239218 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=239218&action=review

> Source/WebKit2/ChangeLog:9
> +        a lot of cpu time serializing ProtectionSpace objects (in particular

CPU

> Source/WebKit2/ChangeLog:46
> +

You need to update the change log to include the WKProcessPool changes.

[Chris Dumez]

Created attachment 239356 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 239356 [details]
Patch

Clearing flags on attachment: 239356

Committed r174369: <http://trac.webkit.org/changeset/174369>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.