Details
-
Bug
-
Resolution: Fixed
-
Major
-
COmanage Registry 3.0.0 (Fancy New Dress)
-
Our development instance of COmanage 3.0.0 runs on a VM with Ubuntu Linux, Apache 2.4, and PHP 7, with 3 GB RAM. It uses a MariaDB 10.1.13 database on a separate database server.
It currently has about 86,000 cm_co_people records.
Description
Login and logout to the COmanage UI became increasingly slow, taking over 60 seconds for a single account. The rest of the interface responded quickly, loading most pages in about a second.
Increasing memory_limit to 1024MB and max_execution_time to 60s in php.ini was necessary to prevent timeouts and errors.
Increasing RAM from 2 GB to 3 GB didn't help.
Upgrading to PHP 7 helped somewhat; memory_limit was reduced to 512MB, and login/logout time was decreased about 30 seconds. But top and vmstat 2 commands showed large CPU and memory spikes during login/logout.
Deleting all cm_co_group_members records with actor_identifier = CSUAPIUser (created by our API calls) resolved the problem. Login now takes about a second, and the rest of the interface remains fast and functional.
We currently don't need the cm_co_group_members records because we use Grouper for group management, but I was just testing a variety of COmanage features.
There were about 4 cm_co_group_members rows for each co_person_id, with 4 different co_group_id values:
- csumembers - Colorado State University Members - created by my API calls
- CO:members:active - automatically created
- CO:members:all - automatically created
- id=0 - created all at once, possibly by my API calls by mistake
So the issue may have been due to bad data I created, and may not be an issue for most COmanage installations, but I am reporting it here in case it's a more general performance issue with group members.