Stupidly slow saving with 1100 usergroups

[tonypartridge]

So a client has a site which has 1,100 usergroups. This is used for course management they restrict access to courses based on user groups and they have 3-6 users groups per client of theirs.

this means when saving a page it takes around 3-4minutes to finish processing in the browser whilst it does it's user group checks from what I can gather, Javascript is not my forte. This makes managing the site very hard and tiresome.

Can we disable validating usergroups via JS? Maybe as a global config option? Since we can handle this serverside and surely we already do as a fall back should anyone has JS disabled as an example.

[GCLW]

I'm guessing it is more because you have a category with 100,000+ articles in it and when you save a new article every single one of those articles has to get its "ordering" field incremented by 1 so the new article will display first.

[tonypartridge]

Not’s not articles we only have 5. Same with the Global configuration, stupidly slow.

On 2 Mar 2018, 14:30 +0000, GCLW [email protected], wrote:

I'm guessing it is more because you have a category with 100,000+ articles in it and when you save a new article every single one of those articles has to get its "ordering" field incremented by 1 so the new article will display first. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ggppdk]

@tonypartridge

hhmm there is no validation for ACL rule fields (you have 12 of every usergroup) the above is because the 'select' field of the rules have 'novalidate' CSS class (i also remember discussion when this was suggested and added)

so it must be something else

I tested global config using 1020 groups,

after global config form is saved -- the page reloads

at that point (but also when i first open global config form) i see very slow page load time (browser trying to execute JS and render HTML)

is the above the issue for you ?

[ggppdk]

To create about 1000 usergroups with some nesting try adding a new task inside groups controller /administrator/components/com_users/controllers/groups.php

then open URL: /administrator/index.php?option=com_users&task=groups.creategroups

public function creategroups()
{
	$db = JFactory::getDbo();
	$vals = array();
	$n = 1000;

	for ($i = 0; $i < 10; $i++)
	{
		$parent_id = !$i ? 1 : 1000 + $i - 1;
		$query = 'INSERT INTO #__usergroups '
				. ' (id, title, parent_id)'
				. ' VALUES (' . (1000 + $i) . ', ' . $db->q('Test group ' . uniqid()) . ', ' . $parent_id . ')';
		$db->setQuery($query)->execute();
	}

	for ($i = 0; $i < $n; $i++)
	{
		//$vals[] = '(0, ' . $db->q('Test group ' . uniqid()) . ', ' . (1000 + (int) ($i % 10)) . ')';
		$vals[] = '(0, ' . $db->q('Test group ' . uniqid()) . ', 1009)';
	}

	$query = 'INSERT INTO #__usergroups '
			. ' (id, title, parent_id)'
			. ' VALUES ' . implode($vals, ',');
	$db->setQuery($query)->execute();

	$table = JTable::getInstance('Usergroup', 'JTable', array());
	$table->rebuild();

	JFactory::getApplication()->enqueueMessage('Added 10 + ' . $n . ' usergroups', 'notice');
}

[Fedik]

Can we disable validating usergroups via JS?

As @ggppdk noted It is disabled, at least should be. There can be 100 other script which tried to do something with inputs in the form.

[tonypartridge]

I’ll run some test, but when I remove usergroup display in the form it’s fast again.. they do have a load of access levels too.

On 3 Mar 2018, 17:13 +0000, Fedir Zinchuk [email protected], wrote:

Can we disable validating usergroups via JS? As @ggppdk noted It is disabled, at least should be. There can be 100 other script which tried to do something with inputs in the form. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Fedik]

@tonypartridge please add more detail:

• which component?
• which form?
• whether there any non-core plugins involved?

[Fedik]

I have made test on Article form (with 1000 user groups), and validation took only ~40ms, however whole submit ~400ms, but still not 3-4 minutes:

But the initial rendering take a loooot, mainly because choosen.js. And Global Configuration form become inaccessible due slow rendering.

Anyway. Only good solution is to detach the rule field from the main form, make editing in the modal or in another window. Otherwise this issue will stay forever :wink:

[tonypartridge]

Try it with access levels of 1000 one to every group too?

On 4 Mar 2018, 11:20 +0000, Fedir Zinchuk [email protected], wrote:

I have made test on Article form (with 1000 user groups), and validation took only ~40ms, however whole submit ~400ms, but still not 3-4 minutes: But the initial rendering take a loooot, mainly because choosen.js. And global configuration become inaccessible due slow rendering. Anyway. Only good solution is to detach the rule field from the main form, make editing in the modal or in another window. Otherwise this issue will stay forever 😉 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Fedik]

Try it with access levels of 1000 one to every group too?

nope, I missed this part sorry :wink: but, it not affected by validation, Can be due: jQuery("#permissions-sliders select").attr("disabled", "disabled"); and permissions.js

Anyway there only one good solution, I already wrote. if someone brave enough to do it, that would be cool :wink:

[dgrammatiko]

@Fedik let's do that in J4, also making this modal means one less tab which is also another win (simplification)! 👍

[tonypartridge]

Great idea for J4 massive performance boost for large ACL sites.

On 4 Mar 2018, 14:18 +0000, Dimitri Grammatikogianni [email protected], wrote:

@Fedik let's do that in J4, also making this modal means one less tab which is also another win (simplification)! 👍 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[coolcat-creations]

is this a duplicate of #30101 ?

[brianteeman]

ooks like they are the same although this one is the oldest

[Hackwar]

I've tested this with 1000+ usergroups and 1000+ viewlevels on Joomla 5.2 and while we have a noticeable delay because of the number of usergroups and thus the input vars send to the server and all that, the delay is maybe around 5 seconds, not minutes and not something unexpected for such a large number. I expect the improvement to come from the removal of chosen in most select fields. I think this is an acceptable situation right now and thus will close this issue here. If you disagree with this, please report back and we can open this issue again.