Maximo Open Forum

 View Only

 Maximo running slowly for some users and I can't figure out why

  • Administration
  • Security
Travis Herron's profile image
Travis Herron posted 04-07-2021 17:51
We're currently on Maximo 7.6.0.8, on-premises.  Last week, I installed some Windows Updates on our Maximo servers, and everything seems to have gone well.  The servers -- and we're talking about one server with the SQL Server database and one with WebSphere/IHS/Maximo -- were of course rebooted when the patching was done.

Sometime the next day, our Help Desk Agents start calling saying Maximo is running really slowly.  Validating fields takes 10 - 15 seconds each (where it should normally be pretty instantaneous).  I'm sitting at my desk and follow the same steps they're taking, and it works fine for me.  I found a few Escalations that benefitted from having their schedules adjusted, and users said that helped some but it was still slower than normal.

I found a user today who:
--had a faster Speedtest result than I did on my machine
--has a better processor in her machine than mine
--has 16GB of RAM to my 8GB

so she has better hardware (and wasn't running a ton of other stuff) but she was encountering this Maximo slowness problem.  So I go to her office, log into Maximo, and it works fine for me.  We log in as her and it's slow.

She is a member of multiple Security Groups, so I deleted her from all but one Group (to see if it was somehow related to combining Group privileges).  Still slow.

I delete her from that last Group she's in, and add her to the one Security Group I'm in.  We log in as her and all of a sudden it's fast.  I then put her Group memberships back to how they were, and it's slow for her again.  I add my one Security Group to her multiple Security Groups, and it's fast again.

I call a different Help Desk Agent in a different office and tell her I'm adding her to my Security Group (while retaining her existing Groups) to see if it'll speed her up.  I ask her to log out, log in, and test it out.  She says it's noticeably faster.

All that we did in all this testing was go to Work Order Tracking, click the Insert icon, and type a partial value in the Reported By field to see how long it would take to validate.

I'm stumped.  Why would it all of a sudden work a lot more quickly once they are members of my Security Group?  On all of the Security Groups involved here:

--none have conditions associated with the Read, Delete, Save, or Insert sigoptions for Work Order Tracking
--none have Collection or Attribute Restrictions
--though some have Data Restrictions, none have Restrictions are on the WORKORDER object



I'm hoping someone here can contribute either ideas as to why this is happening, or practical steps I could take to try to troubleshoot it, like which Loggers need to be changed to what level.
Steven Shull's profile image
Steven Shull
The fact that you're adding your group to all of their existing and it works quickly makes it seem like to me that it's probably related to your group having All Site access and their groups being explicitly granted access to specific sites. It wouldn't really explain why it's all of a sudden so much slower, but we have seen queries get pretty inefficient as the Maximo framework appends a really inefficient query to see if they should be able to access records that are defined at a site level.

Can you confirm that none of their other groups have the checkbox enabled to access all sites and that the group you add to improve their performance does?
Travis Herron's profile image
Travis Herron
Some more info:

We only have one Site in our Maximo environment. Naturally, we are all in the MAXEVERYONE Security Group, which has no Site access listed.

We don't have Maximo for Service Providers.

There were three people involved in my testing this:

  1. me, who (not counting MAXEVERYONE) was in one Security Group, and that Group had "Authorize for All Sites" checked.
  2. Telecom Dept. Help Desk Agent, was a member of multiple Security Groups, all of which had "Authorize for All Sites" checked.
  3. Maintenance Dept. Help Desk Agent, was a member of multiple Groups; some had "Authorize for All Sites" checked, some specifically listed our one Site.  I have since changed this so that all her Groups have "Authorize for All Sites" checked.

--all of us have our one Site listed as the Default Insert Site, and the box to use it as a Display Filter is checked

--none of the Security Groups in question here are "Independent of Other Groups"



We've done further experimentation, and we've pretty much narrowed the problem down to just a few issues with Work Order Tracking:

--I removed the user from my Security Group, so she should have been back to how her permissions used to be, except that all Groups she's a member of would now have Authorize for All Sites selected.
--She logged out, logged in, tried to insert a Work Order, and immediately commented that it was back to "slow mode" -- as we expected.
--Really the only slowness was in creating the Work Order, validation of the Reported By field, selecting/applying an Owner Group, and changing Status.  Other data validations, such as the Work Type field (against a simple Value List) and Location (against a list from another application) worked fine.
--As a test, I asked her to create a new Person Group and add a member to that Group.  She said it worked fine.
--As for those Work Order Tracking issues:

1) I have multiple Automation Scripts (it would be one, but it got too long!) running upon choosing an Owner Group that set the value of Supervisor, Work Group, and in some cases Lead, and in some cases my also do a Status change.
2) I have multiple Conditional Expressions that control which Statuses are available dependent upon what the current Status is.
3) There is a crossover domain on the Reported By field that copy the person's default email and phone number to custom fields on the Work Order. 
4) All of these should affect every User, my Security Group is not exempt.
5) These three things have been in place for a long time and have not changed recently.
6) (In case you couldn't tell) We're not using Workflow.