-
- Influencer
- Posts: 22
- Liked: never
- Joined: Sep 16, 2020 6:46 am
- Full Name: Yusaku Furuhashi
- Contact:
Why the number of objects matter?
Hello team,
I would like to know why the number of objects matter for a Proxy server instead of the number of files or mails ? What kind of things affect the behavior of Proxy server? Because I need to explain the reason for my job design sizing. Is that correct if I assume the number of objects is 15,000 for 5,000 Teams since each Team has a mailbox, a site, and a Team itself?
Thanks,
Yusaku
I would like to know why the number of objects matter for a Proxy server instead of the number of files or mails ? What kind of things affect the behavior of Proxy server? Because I need to explain the reason for my job design sizing. Is that correct if I assume the number of objects is 15,000 for 5,000 Teams since each Team has a mailbox, a site, and a Team itself?
Thanks,
Yusaku
-
- Product Manager
- Posts: 8191
- Liked: 1322 times
- Joined: Feb 08, 2013 3:08 pm
- Full Name: Mike Resseler
- Location: Belgium
- Contact:
Re: Why the number of objects matter?
Hi @yusaku
The reason why the number of objects count is because of the connections. While everything in M365 seems to be fully connected, the reality is that it are all separated services. To give an example with a user: If you backup a user, we need to connect to:
* Exchange online (twice if archive needs to be protected also)
* SharePoint Online (for OneDrive for Business files)
* SharePoint Online (for personal site, if that is being used)
So that makes, if all is used, 4 connections so 4 objects. Teams is the same, it contains a mailbox, a SharePoint Site, a OneDrive for business and the team itself. But considering that it most likely has less information on the OneDrive for Business, you indeed can calculate around 3 objects.
Unfortunately it is not exact science (I wish it was ) and the calculation of objects is for reference and sizing so we do not put a hard stop on a proxy if you go over it. Ideally, they give you the opportunity to start with a proxy and build up the jobs step by step (also for throttling)
The reason why the number of objects count is because of the connections. While everything in M365 seems to be fully connected, the reality is that it are all separated services. To give an example with a user: If you backup a user, we need to connect to:
* Exchange online (twice if archive needs to be protected also)
* SharePoint Online (for OneDrive for Business files)
* SharePoint Online (for personal site, if that is being used)
So that makes, if all is used, 4 connections so 4 objects. Teams is the same, it contains a mailbox, a SharePoint Site, a OneDrive for business and the team itself. But considering that it most likely has less information on the OneDrive for Business, you indeed can calculate around 3 objects.
Unfortunately it is not exact science (I wish it was ) and the calculation of objects is for reference and sizing so we do not put a hard stop on a proxy if you go over it. Ideally, they give you the opportunity to start with a proxy and build up the jobs step by step (also for throttling)
-
- Influencer
- Posts: 22
- Liked: never
- Joined: Sep 16, 2020 6:46 am
- Full Name: Yusaku Furuhashi
- Contact:
Re: Why the number of objects matter?
Hello Mike,
Thank you for answering my question It is really helpful. I understood that connections are related to the number of objects. Let's suppose I made one single job for 5,000 Teams (15,000 objects) and there are few items in each Team, and the thread number of the proxy server is 64 as default. Would it be possible that the connections will increase to 15,000? Or, If the backup processes of small size of Team finish earlier, the connections will be disconnected as soon as the process finished? Additionally, please let me know how to check the current number of connections? (netstat?)
Regards,
Yusaku
Thank you for answering my question It is really helpful. I understood that connections are related to the number of objects. Let's suppose I made one single job for 5,000 Teams (15,000 objects) and there are few items in each Team, and the thread number of the proxy server is 64 as default. Would it be possible that the connections will increase to 15,000? Or, If the backup processes of small size of Team finish earlier, the connections will be disconnected as soon as the process finished? Additionally, please let me know how to check the current number of connections? (netstat?)
Regards,
Yusaku
-
- Product Manager
- Posts: 8191
- Liked: 1322 times
- Joined: Feb 08, 2013 3:08 pm
- Full Name: Mike Resseler
- Location: Belgium
- Contact:
Re: Why the number of objects matter?
Correct, if you have 64 connections, they will run in parallel and when one is done, it will start with the next one. It won't wait until others are finished. I see no issues in 15.000 teams on a proxy server as long as it has enough memory and cpu power.
For the connections itself, I am not sure if you will be able to see those through netstat to be honest.
For the connections itself, I am not sure if you will be able to see those through netstat to be honest.
-
- Influencer
- Posts: 22
- Liked: never
- Joined: Sep 16, 2020 6:46 am
- Full Name: Yusaku Furuhashi
- Contact:
Re: Why the number of objects matter?
Hello Mike,
Thank you for answering. You mean there is no way to check the current number of connections? And you also mean you see no issues in 15,000 teams (45,000 objects) on a proxy server as long as it has enough memory and cpu power (8core 32GB RAM)?
Thanks,
Yusaku
Thank you for answering. You mean there is no way to check the current number of connections? And you also mean you see no issues in 15,000 teams (45,000 objects) on a proxy server as long as it has enough memory and cpu power (8core 32GB RAM)?
Thanks,
Yusaku
-
- Product Manager
- Posts: 8191
- Liked: 1322 times
- Joined: Feb 08, 2013 3:08 pm
- Full Name: Mike Resseler
- Location: Belgium
- Contact:
Re: Why the number of objects matter?
@yusaku
I indeed see no issues in that number, however, you might want to consider splitting it up in a few jobs (same proxy, same repository if needed) just to make sure that you spread the load a bit
I indeed see no issues in that number, however, you might want to consider splitting it up in a few jobs (same proxy, same repository if needed) just to make sure that you spread the load a bit
Who is online
Users browsing this forum: No registered users and 9 guests