Hey All,
I've tried and tried to ask the powers that be this question:
Why is there a 1000 count limit on the number of Sites that can be created under the GSM?
Our GSM has had the updates all pushed through with the 50 per page options and we've found that the response times of loading etc.. have all been good since those updates. I've not complained about GSM performance in ages now.
I'm looking for an actual technical explanation as to why there can't be more than 1000 Sites on a GSM. I know MSP's that have thousands and thousands of endpoints on a GSM, but why the limit of the number of sites I can create? This is the only way I can really account for my clients by separating them off into sites. Now I'm forced to juggle two GSMs in order to continue.
Does going over 1000 cause Webroot to implode or something? Cause after the updates, I don't buy the idea that it's not responsive etc... You'd think that if this is cloud based and scalable databases that we could simply adjust the limit with a few keystrokes and continue on.
Extrememly frustrating.
Thanks
John
Nerds On Site
Page 1 / 1
I'm guessing this is a hard coded limit to make sure that the GSM console doesn't get overloaded. Let me ask around and find out a definite answer for you.
yeah, I don't buy the overloaded argument as since they've moved to only showing x number of sites per page, the GSM is actually fairly responsive.
And again, if this is supposed to be an enterprize ready solution, you'd think this should have been designed from the get to to be massively scalable regardless of site/seat counts.
And again, if this is supposed to be an enterprize ready solution, you'd think this should have been designed from the get to to be massively scalable regardless of site/seat counts.
Ok got some more background for you on how the limit was chosen:
1. While you might not be seeing any performance issues, there are certain operations and reports that get slow when the # of sites goes up. You might not be running those particular reports or functions which is why you aren't running into problems.
2. While the total # of sites isn't the absolute limit, it's the easiest way to limit things on the back end. The true limit is a combination of sites and installs per site, but we had to pick something that was the limit for most. If you're average installs per site is lower than the average that could be why you are running fine at 1,000 sites, whereas for most others at that level the performance wouldn't be up to snuff. One other variable is how many admins you have working in the same console at the same time.
Hopefully that helps - I know it would be easier to have all of your sites in one console, but our dev folks had to pick a line in the sand that we can test against and guarantee sufficient performance.
1. While you might not be seeing any performance issues, there are certain operations and reports that get slow when the # of sites goes up. You might not be running those particular reports or functions which is why you aren't running into problems.
2. While the total # of sites isn't the absolute limit, it's the easiest way to limit things on the back end. The true limit is a combination of sites and installs per site, but we had to pick something that was the limit for most. If you're average installs per site is lower than the average that could be why you are running fine at 1,000 sites, whereas for most others at that level the performance wouldn't be up to snuff. One other variable is how many admins you have working in the same console at the same time.
Hopefully that helps - I know it would be easier to have all of your sites in one console, but our dev folks had to pick a line in the sand that we can test against and guarantee sufficient performance.
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.