I upgraded from osticket osTicket v1.10.4 to the latest v1.15.1 (fe1d1f8), and had to downgrade/roll-back because viewing closed tickets (the "closed tickets" view from the navbar) was very slow, 30+sec.

Server info is:
Web Server Software Apache/2.4.39 (cPanel) OpenSSL/1.0.2s mod_bwlimited/1.4
MySQL Version 5.6.49
PHP Version 7.3.8

Going to closed tickets view is fast if I use a new-install of osticket v1.15.1. But if I use the updated database that has all of our old tickets (ost_thread_entry has 15K rows) it becomes slow.

I saw a couple folk have had similar issues, across various versions, but I didn't see recommendations for trouble shooting this on a cPanel system on new osticket version.

So our live system is back to the older version, and I have a duplicate upgraded installation of osticket running for testing purposes. Any suggestions welcomed! Thank you

@halcyonyarn

First make sure you are running MariaDB 10.2+ (or MySQL’s equivalent version) and if so ensure all your tables are InnoDB (not MyISAM). Next ensure your server has enough resources (CPU and RAM). Typically when it’s slow loading you don’t have enough resources for MySQL to process all the data.

If you have a ton of closed tickets that could be why it’s slow to load. As MySQL has to scan many, many records to get the counts, columns, etc. You could also look into truncating some data to clean up database space.

Cheers.

    Thank you KevinTheJedi . The tables were MyISAM; unfortunately, converting them to InnoDB does not seem to have helped. It's on a capable dedicated (8-core 16GB ram) server that's not maxing out... but on the other hand the MySql (5.6.49) version is probably right at or around the minimum MariaDB equivalent.

    I have integrated the information from closed tickets into our in-house CRM app, which is very helpful to staff to be able to look back at a customer and their history of help... So, we would really like to keep old data. And while 15,000 closed tickets is a lot, there must be many folk who have many more?

    It's funny that osTicket v1.10 runs very fast, but v1.15 is so slow, bummer. We will be upgrading our MySql (and server) after the holidays, so hopefully that'll help... Otherwise, at the moment, I guess we'd be stuck staying with v1.10.4...

    Any further thoughts welcome. Thanks again!

      @halcyonyarn

      That's because v1.10.4 didn’t have Custom Queues. Queues for the old versions were super basic and didn’t have really any complexity. We had to rewrite how all of it works for Custom Queues.

      Yes, there are people with much, much more Tickets with little to no issues. Recently, there was an instance that was super slow queue loading, slow queue counts, etc. and we found that converting the tables to InnoDB, doing small MariaDB configs, and upgrading server resources fixed the issues. I bet it’s due to your MySQL version so hopefully upgrading that will help.

      Cheers.

      5 months later

      Finally getting back to this! @KevinTheJedi it seems to run well under MySQL 8 (also I did change to InnoDB). Curious, do you remember any specific MariaDB configs, that you'd noted above, were helpful? When I run on the same testing machine but using MariaDB 10 instead of MySQL 8, it takes around 8sec to load closed tickets. So, that's faster than the original issue under MySQL 5 but still slow... Mostly curious at this point, would like to move to MariaDB but happy to use what works. Thanks!

      @halcyonyarn

      Curious, do you remember any specific MariaDB configs, that you'd noted above, were helpful?

      Not that I can recall. Was minor MySQL tuning configs.

      What's the query time difference for MySQL 8 vs MariaDB 10?

      Cheers.

      With MySQL 8 it's very responsive, <1sec, with Maria 10, 8sec+/-. First time working with MariaDB, just using default configs from my DDEV developmen tool... Will have to learn more... Thanks!

        a year later

        halcyonyarn

        Having the same issue here. Did you every figure anything out with MariaDB?

          6 months later
          7 days later
          Write a Reply...