@rolek I would advise that you that you star your own thread with your specific environment information and log errors, etc.

2 months later

KevinTheJedi

Well, depending on how crazy the agents setup these queues, no amount of server config/resources are going to be able to mitigate the potential insane query that is generated by that all in one approach. I mean, not trying to be mean, but this is just bad design. It's giving the end user more than enough rope to hang themselves and the rest of the team with.

Look at the query @fnixt posted.

There's no defending that mess... the patch needs to be made official.

      eteich

      We know slower systems and non-optimized systems can have issues which is why we have an optimization on our todo list (to account for the lower end systems).

      Cheers.

        4 months later

        Hi. I am the initial poster.

        Nobody really looked at my output/findings i think.

        i think you can clearly see that there is a inefficient way of the query when having multiple criteria.
        i am not sure this is fixed. we just delete agent custom save searches when we experience the issue.

        @ntozier cpu/memory is not an issue. we have big server farms and selfhost and can assign immense ammount of cpu/cores/memory on SSD arrays.... bad query kills every hardware.

        our environment only has 5 agents logged in normaly.
        tickets something over 12k

        i dont want to complain! we love osticket! thanks to EVERYONE putting work in this great product

        if we struggle, we struggle with the fixed width of osticket screen (i think something below 960px)
        we are in IT since 1997, so we know how hard "simple" things can be to change if gone that road at the beginning...

        if anyone had a nice or elegant way to "fix" that limitation, we really appreciate a hint. or we also pay for someone willing to do some work on that. we tried some osticket overlays like osticketawesome.com but had other issues with these.

        we saw in 2.0 that should be fixed :-) thanks to everyone involved !

        stay safe!
        Marco

        21 days later

        KevinTheJedi
        It it a good solution, thank you!
        But: After comment out the try part, all agents see all ticket counters (not just tickets what the agent has access to), even where they don't see tickets in the queue.

            9 months later

            KevinTheJedi
            Your solution works perfectly. I have many queries to manage tickets with my Team and now I have instant result. Previously, I waited up to 2 min.

              6 months later

              For example the statistics should count only on user/agent login once.
              And till he login again he sees the same statistical data.
              If user/agent wana to update statistical data he should to login again which should not be so difficult for user/agent to login few times per day (when new stats are needed)

                mLipok

                That’s how it works. Counts are calculated for each Agent on login. They are cached for 5 minutes then recalculated afterwards. To refresh counts immediately you can logout and back in.

                Cheers.

                  So. to be more specific.
                  How to stop the recalculation after each passed 5 minutes ?

                    mLipok

                    Modify the codebase to remove the recalculation. Be careful though as you may disable it on login as well.

                    Cheers.

                      Write a Reply...