When I see the task manager of Google's Chrome I could see few (each) tabs run under individual process and group of tabs run under a single process. Out of curiosity, I searched to know why it runs as multiple process instead of multiple threads. And one thing which brought to my attention is when it runs as a single process and spawns multiple threads there could be few limitations/drawbacks like,
1) Limitation on number of threads that could be created
2) When a single tab becomes unresponsive the entire application would be come useless and we have to quit chrome and restart it due to some misbehaving site.
A few mentioned that Chrome uses single process per domain, but here it doesn't seem to be true.
I'm still not clear on,
1) When Chrome decides to spawn a new process?
2) What are the other advantage of running individual tabs under separate process?
3) How cookies are shared between tabs when each of them run under different process? Is this happening via interprocess communication? If yes, will it be too costly? And will it impact the other tab's (ie' the web page) performance?
After asking this question, I came to see this article (Multi Process Architecture of Chromium) and it answered my question (1).
When Chrome decides to spawn a new process?
Once Google Chrome has created its browser process, it will generally create one renderer process for each instance of a web site you visit. This approach aims to keep pages from different web sites isolated from each other.
You can think of this as using a different process for each tab in the browser, but allowing two tabs to share a process if they are related to each other and are showing the same site. For example, if one tab opens another tab using JavaScript, or if you open a link to the same site in a new tab, the tabs will share a renderer process. This lets the pages in these tabs communicate via JavaScript and share cached objects. Conversely, if you type the URL of a different site into the location bar of a tab, they will swap in a new renderer process for the tab.
They place a limit on the number of renderer processes that they create (as 20 in most cases). Once they hit this limit, they'll start re-using the existing renderer processes for new tabs.
What are the advantage of running tabs under different process?
Google Chrome takes advantage of these properties and puts web apps and plug-ins in separate processes from the browser itself. This means that a rendering engine crash in one web app won't affect the browser or other web apps. It means the OS can run web apps in parallel to increase their responsiveness, and it means the browser itself won't lock up if a particular web app or plug-in stops responding. It also means they can run the rendering engine processes in a restrictive sandbox that helps limit the damage if an exploit does occur.
Interestingly, using multiple processes means Google Chrome can have its own Task Manager (shown below), which you can get to by right clicking on the browser's title bar. This Task Manager lets you track resource usage for each web app and plug-in, rather than for the entire browser. It also lets you kill any web apps or plug-ins that have stopped responding, without having to restart the entire browser.
Related
When 2 tests are running in Chrome, i have observed that too many Google Chrome(32 Bit) processes are running in Task manager, Is this a correct behavior of Chome Driver
When multiple automated tests are getting executed through Google Chrome you must have observed that there are potentially dozens of Google Chrome processes running which can be observed through Windows Task Manager's Processes tab.
Snapshot:
As per the article SOLVED: Why Google Chrome Has So Many Processes for a better user experience Google Chrome initiates a lot of windows background processes for each tab that have been opened by your Automated Tests. Google tries to keep the browser stable by separating each web page into as many processes as it deems fit to ensure that if one process fails on a page, that particular process(es) can be terminated or refreshed without needing to kill or refresh the entire page.
However, from 2018 onwards Google Chrome was actually redesigned to create a new process for each of the following entities:
Tab
HTML/ASP text on the page
Plugin those are loaded
App those are loaded
Frames within the page
In a Chromium Blog Multi-process Architecture it is mentioned:
Google Chrome takes advantage of these properties and puts web apps and plug-ins in separate processes from the browser itself. This means that a rendering engine crash in one web app won't affect the browser or other web apps. It means the OS can run web apps in parallel to increase their responsiveness, and it means the browser itself won't lock up if a particular web app or plug-in stops responding. It also means we can run the rendering engine processes in a restrictive sandbox that helps limit the damage if an exploit does occur.
As a conclusion, the many processes you are seeing is pretty much in line with the current implementation of google-chrome
Outro
You can find a relevant discussion in How to quit all the Firefox processes which gets initiated through GeckoDriver and Selenium using Python
I am new to mobile website development, and facing this issue where I want to refresh data on the website in every 30 sec which is invoked from the client side and server provides the data in response. Problem is when I close the browser or when the browser goes in background it stops working. Is there any thing we can do to make this thing possible?
Have a look at the Android Developers - Processes and Threads guide. You'll get a deeper introduction to how process life-cycles work and what the difference is between the states for background- and foreground processes.
You could embed your web app in a WebView. This way you could deal with the closing browser case: you could provide a means to "exit" the app that involves closing only your container activity. That way the timers you have registered in javascript will still be running in the 'WebViewCoreThread'. This is an undesirable behavior and a source of problems, but you can take advantage of it if you want (just make sure you don't run UI-related code there). I've never tested this in Kit Kat (which uses a different WebView based on Chrome) but works for previous versions, as I described here.
Now the user can always close any app. Even without user interaction, the OS can kill your app on low memory. So just give up on long-running apps that never end, because the OS is designed in such a way this is simply not possible.
You could go native and schedule Alarms using the AlarmManager.
Just checked this out on the Android KitKat WebView and as per Mister Smith's comments the javascript will continue executing in the background until the Activity is killed off:
Just tested with this running in a WebView:
http://jsbin.com/EwEjIyaY/3/edit
My gut instinct is that if the user has moved your application into the background, there seems little value in performing updates every 30 seconds, it makes more sense to just start updating again once the user opens the device up and cache what information you currently have available to you.
As far as Chrome for Android goes the same is happening, as Chrome falls into the background the javascript is still running.
If you are experiencing different behaviour then what exactly are you seeing and can you give us an example?
How does a browser handle creation of new tabs. Does it fork or create a new thread? Can you point me how I choose between creating a new thread and a child process.
Some modern browser these days create separate processes for new tabs. The reason is that if some site (tab) contains malicious code and is for example frozen the rest of the browsed sites can be still seen.
If you used for example Chrome and you would be on Windows, you could try to kill some chrome.exe processes and you will see only one tab will die. However, in case of chrome it is not completely 1 to 1 (tabs to processes). Some processes are vital for running the browser as is (if you kill them the whole browser will die), so be aware of that if you are gonna to try. :)
Note that almost all browser now have separate processes for plugins (3rd party plugins written e.g. using Netscape API). The reason is the same as with tabs (and is even more understandable).
To find answer for your second question, look for example here:
http://jayant7k.blogspot.com/2010/01/for.html
I went through couple of articles that talk about Web Workers in HTML5 and I was not able to clearly understand the following:
Is the life cycle for a web worker limited to a single page or across pages of an domain?
Is the life cycle for a web worker persistant after a page is loaded?
Are web workers a better option to using than an ajax call within setInterval?
Appreciate if someone could help me shed some light on the above questions.
Is the life cycle for a web worker limited to a single page or across pages of an domain?
Dedicated worker is limited to a single page, while shared worker can be related to many webpages
Is the life cycle for a web worker persistant after a page is loaded?
It could be persistent if it has onmessage() defined, and it could also returns after execution, if I understand correctly. In spec it says: let that run until it either returns, fails to catch an exception, or gets prematurely aborted by the "kill a worker" or "terminate a worker"...
Are web workers a better option to using than an ajax call within setInterval?
It depends. You can't simply say it is better or not. At the moment Web worker is mainly used for offloading complex JavaScript algorithms to run in the background.
I was reading googlebooks on chrome, where they talk about why they decided to spin up a process to host browser tab, every time you created a new tab.'
So
2 tabs = 2 chrome processes
3 tabs = 3 chrome processes and so on .. right??
But i opened up some 20 or so tabs, but in task manager, i could only find 3 chrome processes..
What is going on??
I was taught that creating a process is an expensive proposition in terms of resources needed, and there are other light weight options available (like app domains in .net for ex)..
So is chrome taking some hybrid approach?? Create few processes and then start hosting additional tabs inside those limited set of processes??
it's being hosted in the first process. open up chrome. you'll see 2 processes (manager and initial tab). then open 10 more tabs, you'll notice the second process's memory jump a lot. then type in google.com or something into the first tab, and you'll see a new process get spawned.
also notice, if you do shift+esc and brink up the task manager in chrome, all those tabs will be grouped together, one w/ memory, the others without.
Don't forget that if two sites share a session, they share a process. So following a link from one site that opens a new page will be in the same session (and thus the same process).
For each tab created with Ctrl+T, you should get a new process.
I've also noticed that tabs browsing the same domain ar grouped in the same process. So if you have 3 tab browsing stackoverflow.com, those three tabs will appread as one process
Process creation is relatively expensive, certainly compared to thread creation. But the frequency of process creation in Chrome is very slow, so the real issue is the amount of resource overhead vs other techniques.
The Google team figured that the benefits of a separate process model justified the resource costs. Given the current resources on desktop machines this trade off makes a lot of sense.