Keep renderer a while to support keepalive option in Fetch API

[Yutaka Hirano]

Hi,

We are planning to support "keepalive" option in Fetch API. Here is the design doc. After some discussion, we believe that the third option, "Keep renderer alive for a while", is the best from layering and long term code maintainability reasons.

The problem is, keeping the renderer costs memory. Is the cost acceptable?

I recently added a histogram "Net.DetachableResourceHandler.Duration" which measures how long does a SendBeacon request take. According to the data from Windows and Android canary, about 90% requests finish in 1sec and about 99% requests finish in 10sec. I would propose to keep a renderer process at most 30sec. This is the same value as the current SendBeacon timeout.

Comments will be appreciated.

Thanks,

[Kentaro Hara]

My main concern is a case where a renderer navigates to a new renderer. This proposal means that we need to keep the old renderer alive for some time, probably overlapping with the page load of a new renderer. This may significantly increase the peak memory usage (esp on Android devices).

However, I don't think I have a good sense about this. I want to hear thoughts of other people.

--

Kentaro Hara, Tokyo, Japan

[PhistucK]

Will that mean that when you close a tab that uses fetch with keepalive enabled, it will not close until the procedure is done? This is a very bad user experience (and partially why sendBeacon exists, right?).

If not, will that mean that the browser will lie to the user and keep renderers alive even though all of their respective tabs are gone? They will show up as zombie processes from the perspective of the user. This is bad.

Even disregarding the memory and performance concerns, I think both of those options are bad. Moving the logic to the browser processes is much more preferred from the perspective of the user.

It does not have to be included in the network service, there could be a new CORS (or similar) service that only concerns those checks and logic. It could be available to the renderer and to the browser, so in a regular fetch, it will be used by the renderer and in keepalive/sendBeacon, it will be used by the browser (when needed).

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwCkySUW8aftKc8TjsDDsUSZ7Hpq7CjSioF6RBKPQ2x2A%40mail.gmail.com.

[Nasko Oskov]

On Mon, May 1, 2017 at 4:55 AM, Kentaro Hara <har...@chromium.org> wrote:

My main concern is a case where a renderer navigates to a new renderer. This proposal means that we need to keep the old renderer alive for some time, probably overlapping with the page load of a new renderer. This may significantly increase the peak memory usage (esp on Android devices).

This is already the case with cross-process navigations. When the existing document has an unload handler, we execute it async from the new navigation in the new process. The new document is committed and as part of cleaning up the old document, we run the unload handler. Therefore we always have two processes existing and for how long it depends on the time the unload handler takes.

 

However, I don't think I have a good sense about this. I want to hear thoughts of other people.

On Mon, May 1, 2017 at 8:01 PM, Yutaka Hirano <yhi...@chromium.org> wrote:

Hi,

We are planning to support "keepalive" option in Fetch API. Here is the design doc. After some discussion, we believe that the third option, "Keep renderer alive for a while", is the best from layering and long term code maintainability reasons.

The problem is, keeping the renderer costs memory. Is the cost acceptable?

I recently added a histogram "Net.DetachableResourceHandler.Duration" which measures how long does a SendBeacon request take. According to the data from Windows and Android canary, about 90% requests finish in 1sec and about 99% requests finish in 10sec. I would propose to keep a renderer process at most 30sec. This is the same value as the current SendBeacon timeout.

Comments will be appreciated.

Thanks,

--

Kentaro Hara, Tokyo, Japan

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

[John Abd-El-Malek]

On Mon, May 1, 2017 at 6:54 AM, Nasko Oskov <na...@chromium.org> wrote:

On Mon, May 1, 2017 at 4:55 AM, Kentaro Hara <har...@chromium.org> wrote:

My main concern is a case where a renderer navigates to a new renderer. This proposal means that we need to keep the old renderer alive for some time, probably overlapping with the page load of a new renderer. This may significantly increase the peak memory usage (esp on Android devices).

This is already the case with cross-process navigations. When the existing document has an unload handler, we execute it async from the new navigation in the new process. The new document is committed and as part of cleaning up the old document, we run the unload handler. Therefore we always have two processes existing and for how long it depends on the time the unload handler takes.

Yep, and there are other cases too like shared workers, service workers, indexeddb that cause a renderer to live longer. GIven 99% of the time this finishes in under 10 seconds, and not all the times the renderer would been killed right away, it makes sense to not add extra complexity to momentarily save this memory.

 

However, I don't think I have a good sense about this. I want to hear thoughts of other people.

On Mon, May 1, 2017 at 8:01 PM, Yutaka Hirano <yhi...@chromium.org> wrote:

Hi,

We are planning to support "keepalive" option in Fetch API. Here is the design doc. After some discussion, we believe that the third option, "Keep renderer alive for a while", is the best from layering and long term code maintainability reasons.

The problem is, keeping the renderer costs memory. Is the cost acceptable?

I recently added a histogram "Net.DetachableResourceHandler.Duration" which measures how long does a SendBeacon request take. According to the data from Windows and Android canary, about 90% requests finish in 1sec and about 99% requests finish in 10sec. I would propose to keep a renderer process at most 30sec. This is the same value as the current SendBeacon timeout.

Comments will be appreciated.

Thanks,

--

Kentaro Hara, Tokyo, Japan

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

[Kentaro Hara]

On Tue, May 2, 2017 at 12:00 AM, John Abd-El-Malek <j...@chromium.org> wrote:

On Mon, May 1, 2017 at 6:54 AM, Nasko Oskov <na...@chromium.org> wrote:

On Mon, May 1, 2017 at 4:55 AM, Kentaro Hara <har...@chromium.org> wrote:

My main concern is a case where a renderer navigates to a new renderer. This proposal means that we need to keep the old renderer alive for some time, probably overlapping with the page load of a new renderer. This may significantly increase the peak memory usage (esp on Android devices).

This is already the case with cross-process navigations. When the existing document has an unload handler, we execute it async from the new navigation in the new process. The new document is committed and as part of cleaning up the old document, we run the unload handler. Therefore we always have two processes existing and for how long it depends on the time the unload handler takes.

Yep, and there are other cases too like shared workers, service workers, indexeddb that cause a renderer to live longer. GIven 99% of the time this finishes in under 10 seconds, and not all the times the renderer would been killed right away, it makes sense to not add extra complexity to momentarily save this memory.

I understand that this is already happening but shared workers are rare cases, right? Or is the process overlapping already happening in many cases?

10 seconds sounds a bit concerning to me since the memory-consuming part of the page loading happens in the first couple of seconds.

According to the data from Windows and Android canary, about 90% requests finish in 1sec and about 99% requests finish in 10sec.

Do we have separate data for Android? I guess the percentage might be biased on Windows.

(Just to clarify: from the architecture perspective, I'm not concerned about the proposal since the process prolonging is already happening. I'm just wondering from the memory perspective.)

 

However, I don't think I have a good sense about this. I want to hear thoughts of other people.

On Mon, May 1, 2017 at 8:01 PM, Yutaka Hirano <yhi...@chromium.org> wrote:

Hi,

We are planning to support "keepalive" option in Fetch API. Here is the design doc. After some discussion, we believe that the third option, "Keep renderer alive for a while", is the best from layering and long term code maintainability reasons.

The problem is, keeping the renderer costs memory. Is the cost acceptable?

I recently added a histogram "Net.DetachableResourceHandler.Duration" which measures how long does a SendBeacon request take. According to the data from Windows and Android canary, about 90% requests finish in 1sec and about 99% requests finish in 10sec. I would propose to keep a renderer process at most 30sec. This is the same value as the current SendBeacon timeout.

Comments will be appreciated.

Thanks,

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwCkySUW8aftKc8TjsDDsUSZ7Hpq7CjSioF6RBKPQ2x2A%40mail.gmail.com.

[Dmitry Skiba]

On Mon, May 1, 2017 at 8:00 AM, John Abd-El-Malek <j...@chromium.org> wrote:

On Mon, May 1, 2017 at 6:54 AM, Nasko Oskov <na...@chromium.org> wrote:

On Mon, May 1, 2017 at 4:55 AM, Kentaro Hara <har...@chromium.org> wrote:

My main concern is a case where a renderer navigates to a new renderer. This proposal means that we need to keep the old renderer alive for some time, probably overlapping with the page load of a new renderer. This may significantly increase the peak memory usage (esp on Android devices).

This is already the case with cross-process navigations. When the existing document has an unload handler, we execute it async from the new navigation in the new process. The new document is committed and as part of cleaning up the old document, we run the unload handler. Therefore we always have two processes existing and for how long it depends on the time the unload handler takes.

Yep, and there are other cases too like shared workers, service workers, indexeddb that cause a renderer to live longer. GIven 99% of the time this finishes in under 10 seconds, and not all the times the renderer would been killed right away, it makes sense to not add extra complexity to momentarily save this memory.

Do we have UMAs for each of those cases? I wonder if anything can be cut on low-end devices.

 

 

However, I don't think I have a good sense about this. I want to hear thoughts of other people.

On Mon, May 1, 2017 at 8:01 PM, Yutaka Hirano <yhi...@chromium.org> wrote:

Hi,

We are planning to support "keepalive" option in Fetch API. Here is the design doc. After some discussion, we believe that the third option, "Keep renderer alive for a while", is the best from layering and long term code maintainability reasons.

The problem is, keeping the renderer costs memory. Is the cost acceptable?

I recently added a histogram "Net.DetachableResourceHandler.Duration" which measures how long does a SendBeacon request take. According to the data from Windows and Android canary, about 90% requests finish in 1sec and about 99% requests finish in 10sec. I would propose to keep a renderer process at most 30sec. This is the same value as the current SendBeacon timeout.

Comments will be appreciated.

Thanks,

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwCkySUW8aftKc8TjsDDsUSZ7Hpq7CjSioF6RBKPQ2x2A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALhVsw3U1158Yn6gfenaaVumYNCs5gnj3jU%2B0PtA5zQzw4uOcw%40mail.gmail.com.

[Kentaro Hara]

I chatted about this with Nasko offline.

I learned that the renderer process overlapping is already happening in many cases (not only when we have unload handlers but also we navigate to cross-origin pages). If that is the case, prolonging the renderer for the keepalive fetch API won't be a technology that makes the current situation terribly worse. Hence, assuming that the timeout numbers on Android is good, I'm okay with the proposal.

On the other hand, I'm not fully convinced that it's really a good idea to prolong the lifetime of a renderer process. We should measure the memory impact of the process overlapping (esp on Android) and if it's a problem, we should think about a way to stop prolonging a renderer process (for not only the keepalive fetch API but also the cross-origin navigation cases). I might want to have a larger discussion for this.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALhVsw3U1158Yn6gfenaaVumYNCs5gnj3jU%2B0PtA5zQzw4uOcw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABWS%2BByDTJECAbjznakeiXPjJQep5xYCkvn56p70kan3iVkggQ%40mail.gmail.com.

[Kenji Baheux]

On Tue, May 2, 2017 at 10:19 AM Kentaro Hara <har...@chromium.org> wrote:

I chatted about this with Nasko offline.

I learned that the renderer process overlapping is already happening in many cases (not only when we have unload handlers but also we navigate to cross-origin pages). If that is the case, prolonging the renderer for the keepalive fetch API won't be a technology that makes the current situation terribly worse. Hence, assuming that the timeout numbers on Android is good, I'm okay with the proposal.

On the other hand, I'm not fully convinced that it's really a good idea to prolong the lifetime of a renderer process. We should measure the memory impact of the process overlapping (esp on Android) and if it's a problem, we should think about a way to stop prolonging a renderer process (for not only the keepalive fetch API but also the cross-origin navigation cases).

This is very interesting and would love to follow along.

I'm sure a lot of other folks would also be interested.

Is there a crbug that we could subscribe to?

Thanks!

 

I might want to have a larger discussion for this. 

On Tue, May 2, 2017 at 1:14 AM, 'Dmitry Skiba' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

On Mon, May 1, 2017 at 8:00 AM, John Abd-El-Malek <j...@chromium.org> wrote:

On Mon, May 1, 2017 at 6:54 AM, Nasko Oskov <na...@chromium.org> wrote:

On Mon, May 1, 2017 at 4:55 AM, Kentaro Hara <har...@chromium.org> wrote:

My main concern is a case where a renderer navigates to a new renderer. This proposal means that we need to keep the old renderer alive for some time, probably overlapping with the page load of a new renderer. This may significantly increase the peak memory usage (esp on Android devices).

This is already the case with cross-process navigations. When the existing document has an unload handler, we execute it async from the new navigation in the new process. The new document is committed and as part of cleaning up the old document, we run the unload handler. Therefore we always have two processes existing and for how long it depends on the time the unload handler takes.

Yep, and there are other cases too like shared workers, service workers, indexeddb that cause a renderer to live longer. GIven 99% of the time this finishes in under 10 seconds, and not all the times the renderer would been killed right away, it makes sense to not add extra complexity to momentarily save this memory.

Do we have UMAs for each of those cases? I wonder if anything can be cut on low-end devices.

 

However, I don't think I have a good sense about this. I want to hear thoughts of other people.

On Mon, May 1, 2017 at 8:01 PM, Yutaka Hirano <yhi...@chromium.org> wrote:

Hi,

We are planning to support "keepalive" option in Fetch API. Here is the design doc. After some discussion, we believe that the third option, "Keep renderer alive for a while", is the best from layering and long term code maintainability reasons.

The problem is, keeping the renderer costs memory. Is the cost acceptable?

I recently added a histogram "Net.DetachableResourceHandler.Duration" which measures how long does a SendBeacon request take. According to the data from Windows and Android canary, about 90% requests finish in 1sec and about 99% requests finish in 10sec. I would propose to keep a renderer process at most 30sec. This is the same value as the current SendBeacon timeout.

Comments will be appreciated.

Thanks,

--

Kentaro Hara, Tokyo, Japan

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwCkySUW8aftKc8TjsDDsUSZ7Hpq7CjSioF6RBKPQ2x2A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALhVsw3U1158Yn6gfenaaVumYNCs5gnj3jU%2B0PtA5zQzw4uOcw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

[Nasko Oskov]

On May 1, 2017 18:44, "Kenji Baheux" <kenji...@chromium.org> wrote:

On Tue, May 2, 2017 at 10:19 AM Kentaro Hara <har...@chromium.org> wrote:

I chatted about this with Nasko offline.

I learned that the renderer process overlapping is already happening in many cases (not only when we have unload handlers but also we navigate to cross-origin pages). If that is the case, prolonging the renderer for the keepalive fetch API won't be a technology that makes the current situation terribly worse. Hence, assuming that the timeout numbers on Android is good, I'm okay with the proposal.

On the other hand, I'm not fully convinced that it's really a good idea to prolong the lifetime of a renderer process. We should measure the memory impact of the process overlapping (esp on Android) and if it's a problem, we should think about a way to stop prolonging a renderer process (for not only the keepalive fetch API but also the cross-origin navigation cases).

This will require actually undoing perf optimizations targeting Android, so I'm not entirely sure it is a worthwhile trade off. We could measure and see if we are willing to pay the engineering and complexity cost. However, we cannot fully eliminate process overlap until PlzNavigate ships.

This is very interesting and would love to follow along.

I'm sure a lot of other folks would also be interested.

Is there a crbug that we could subscribe to?

Not at this time. If you file one, let me know so I can add all the relevant folks.

Thanks!

 

I might want to have a larger discussion for this. 

On Tue, May 2, 2017 at 1:14 AM, 'Dmitry Skiba' via platform-architecture-dev <platform-architecture-dev@chromium.org> wrote:

On Mon, May 1, 2017 at 8:00 AM, John Abd-El-Malek <j...@chromium.org> wrote:

On Mon, May 1, 2017 at 6:54 AM, Nasko Oskov <na...@chromium.org> wrote:

On Mon, May 1, 2017 at 4:55 AM, Kentaro Hara <har...@chromium.org> wrote:

My main concern is a case where a renderer navigates to a new renderer. This proposal means that we need to keep the old renderer alive for some time, probably overlapping with the page load of a new renderer. This may significantly increase the peak memory usage (esp on Android devices).

This is already the case with cross-process navigations. When the existing document has an unload handler, we execute it async from the new navigation in the new process. The new document is committed and as part of cleaning up the old document, we run the unload handler. Therefore we always have two processes existing and for how long it depends on the time the unload handler takes.

Yep, and there are other cases too like shared workers, service workers, indexeddb that cause a renderer to live longer. GIven 99% of the time this finishes in under 10 seconds, and not all the times the renderer would been killed right away, it makes sense to not add extra complexity to momentarily save this memory.

Do we have UMAs for each of those cases? I wonder if anything can be cut on low-end devices.

 

However, I don't think I have a good sense about this. I want to hear thoughts of other people.

On Mon, May 1, 2017 at 8:01 PM, Yutaka Hirano <yhi...@chromium.org> wrote:

Hi,

We are planning to support "keepalive" option in Fetch API. Here is the design doc. After some discussion, we believe that the third option, "Keep renderer alive for a while", is the best from layering and long term code maintainability reasons.

The problem is, keeping the renderer costs memory. Is the cost acceptable?

I recently added a histogram "Net.DetachableResourceHandler.Duration" which measures how long does a SendBeacon request take. According to the data from Windows and Android canary, about 90% requests finish in 1sec and about 99% requests finish in 10sec. I would propose to keep a renderer process at most 30sec. This is the same value as the current SendBeacon timeout.

Comments will be appreciated.

Thanks,

--

Kentaro Hara, Tokyo, Japan

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwCkySUW8aftKc8TjsDDsUSZ7Hpq7CjSioF6RBKPQ2x2A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALhVsw3U1158Yn6gfenaaVumYNCs5gnj3jU%2B0PtA5zQzw4uOcw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

[Yutaka Hirano]

> Will that mean that when you close a tab that uses fetch with keepalive enabled, it will not close until the procedure is done? This is a very bad user experience (and partially why sendBeacon exists, right?).

If not, will that mean that the browser will lie to the user and keep renderers alive even though all of their respective tabs are gone? They will show up as zombie processes from the perspective of the user. This is bad.

The latter. As mentioned in other places, we are already doing that for some use-cases.

> Even disregarding the memory and performance concerns, I think both of those options are bad. Moving the logic to the browser processes is much more preferred from the perspective of the user.

It does not have to be included in the network service, there could be a new CORS (or similar) service that only concerns those checks and logic. It could be available to the renderer and to the browser, so in a regular fetch, it will be used by the renderer and in keepalive/sendBeacon, it will be used by the browser (when needed).

CORS service is an interesting idea, but it needs a lot of efforts because we need to rewrite security checks done in the renderer completely. It's also possible that having the service would introduce additional latency.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABc02_%2BGbcLaDdhkD3DKw5sAO-MMOY0bHqapBRg-9xv8jRz%3DpQ%40mail.gmail.com.

[Yutaka Hirano]

On Tue, May 2, 2017 at 12:32 AM, Kentaro Hara <har...@chromium.org> wrote:

On Tue, May 2, 2017 at 12:00 AM, John Abd-El-Malek <j...@chromium.org> wrote:

On Mon, May 1, 2017 at 6:54 AM, Nasko Oskov <na...@chromium.org> wrote:

On Mon, May 1, 2017 at 4:55 AM, Kentaro Hara <har...@chromium.org> wrote:

My main concern is a case where a renderer navigates to a new renderer. This proposal means that we need to keep the old renderer alive for some time, probably overlapping with the page load of a new renderer. This may significantly increase the peak memory usage (esp on Android devices).

This is already the case with cross-process navigations. When the existing document has an unload handler, we execute it async from the new navigation in the new process. The new document is committed and as part of cleaning up the old document, we run the unload handler. Therefore we always have two processes existing and for how long it depends on the time the unload handler takes.

Yep, and there are other cases too like shared workers, service workers, indexeddb that cause a renderer to live longer. GIven 99% of the time this finishes in under 10 seconds, and not all the times the renderer would been killed right away, it makes sense to not add extra complexity to momentarily save this memory.

I understand that this is already happening but shared workers are rare cases, right? Or is the process overlapping already happening in many cases?

10 seconds sounds a bit concerning to me since the memory-consuming part of the page loading happens in the first couple of seconds.

According to the data from Windows and Android canary, about 90% requests finish in 1sec and about 99% requests finish in 10sec.

Do we have separate data for Android? I guess the percentage might be biased on Windows.

(Just to clarify: from the architecture perspective, I'm not concerned about the proposal since the process prolonging is already happening. I'm just wondering from the memory perspective.)

A google employee can see the numbers by oneself, but here are 7days (to Apr 30) data:

Windows:

CDF below 1081 msec: 94.74%

CDF below 10257 msec:  99.36%

Android:

CDF below 1081 msec: 92.62%

CDF below 10257 msec: 98.88%

As I said, they are from Canary.

[Kentaro Hara]

Thanks for the data, hirano-san!

Given that the renderer process is already prolonged in many cases, I think it would be okay to implement the keepalive fetch API as you proposed (if there's no other objection on this thread).

As I mentioned, I'm interested in investigating if we should really prolong the renderer process lifetime or not, but that should be a separate (and larger) discussion.

[Kenji Baheux]

On Tue, May 2, 2017 at 3:22 PM Kentaro Hara <har...@chromium.org> wrote:

Thanks for the data, hirano-san!

Given that the renderer process is already prolonged in many cases, I think it would be okay to implement the keepalive fetch API as you proposed (if there's no other objection on this thread).

As I mentioned, I'm interested in investigating if we should really prolong the renderer process lifetime or not, but that should be a separate (and larger) discussion.

I filed a new Needs-investigation bug to keep track of this.

--

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwCkySUW8aftKc8TjsDDsUSZ7Hpq7CjSioF6RBKPQ2x2A%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan