Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

Version 1.9.12 - very slow [resolved]

Good morning,
I am in the middle of moving from an older 1.6x setup to the current 1.9.12
The upgrade went great, all my data is there, no problems.
we began testing internally and noticed it was extremely slow when creating tickets. It would just sit on the "LOADING" image for a minute or 2.
I was thinking this could be because of email, and re-entered all the SMTP settings, same issue. I even tried with a GMAIL account, same result.
We are using these same email SMTP settings on our current (1.6) build and it is fine.
Everything else in the system is extremely responsive.
Anyone else noticing this?
Any solutions?
Thanks

Comments

  • Have you set up cron or do you use fetch on auto-cron?
    Also have you checked your log which osTicket PHP script takes so long to execute?
  • I have not experienced that.
  • Thank you for the responses, how do I check if it is cron or fetch on auto-cron?
    Also, which logs would i need to check? the php logs?
    Thanks
  • Well if its cron you setup a cron job to run the cron.php.  If its auto cron its at: Admin panel -> emails -> Email Fetching.

    PHP logs.
  • oh we do not do email fetching, not yet anyway.
    it is slow when creating just through the standard "NEW TICKET" under admin or when a client creates a ticket.
    any idea which logs chefkeks was referring to?
    Thanks
  • PHP logs ;)
  • Q: it is slow when creating just through the standard "NEW TICKET" under admin or when a client creates a ticket.
    A: how are you sending email?


    Q: any idea which logs chefkeks was referring to?
    A: PHP logs.
  • email is being sent with gmail accounts, see attached
    these are the same settings being used on our production server, and there is no slow down.

    also, the long ticket creation does not seem to add anything into my php logs, or error.log when it happens.
    I even enabled ALL logging in PHP.
    emailSetup.jpg
    1202 x 671 - 174K
  • Do you have a mail server thats local (maybe on the same network) that you can change to see if the slowness s the network latency between you and googles mail servers?
  • I have used our own SMTP as well, same thing happened.
    gmail was actually quicker which is why we are using it.
  • Hello again, I finally caught something in the log, my colleague and I both tried to do new tickets, just minutes apart and we both experienced the slowdown issue

    [Thu Feb 11
    15:11:46.720294 2016] [:error] [pid 2187] [client 127.0.0.1:33196] PHP Fatal
    error:  Uncaught exception 'Exception' with message 'Unable to index
    content' in /var/www/html/support/it/include/class.search.php:641\nStack
    trace:\n#0 /var/www/html/support/it/include/class.search.php(513):
    MysqlSearchBackend->__index(Array)\n#1 [internal function]:
    MysqlSearchBackend->IndexOldStuff(Array, NULL)\n#2
    /var/www/html/support/it/include/class.signal.php(98):
    call_user_func_array(Array, Array)\n#3 /var/www/html/support/it/scp/autocron.php(69):
    Signal::send('cron', Array)\n#4 {main}\n  thrown in
    /var/www/html/support/it/include/class.search.php on line 641, referer: http://localhost/support/it/scp/settings.php



    [Thu Feb 11 15:13:19.031539 2016] [:error] [pid 2187] [client 127.0.0.1:33236]
    PHP Fatal error:  Uncaught exception 'Exception' with message 'Unable to
    index content' in /var/www/html/support/it/include/class.search.php:641\nStack
    trace:\n#0 /var/www/html/support/it/include/class.search.php(513): MysqlSearchBackend->__index(Array)\n#1
    [internal function]: MysqlSearchBackend->IndexOldStuff(Array, NULL)\n#2
    /var/www/html/support/it/include/class.signal.php(98):
    call_user_func_array(Array, Array)\n#3
    /var/www/html/support/it/scp/autocron.php(69): Signal::send('cron', Array)\n#4
    {main}\n  thrown in /var/www/html/support/it/include/class.search.php on
    line 641, referer: http://localhost/support/it/scp/templates.php?tpl_id=1


    Hope the log helps.

  • Also, this morning, I started from scratch with a copy of our current 1.6 version, and I upgraded to 1.8 LTS, same issue when opening tickets.
  • hrmmmm im not sure, the system is actually pretty responsive when going through tickets, click in them to view, etc.
    There is just something weird about opening and closing tickets...
  • in my occurs osTicket status bar carries, but the page takes to load, with the waiting browser
  • @mfelber
    thank you for the link, I read through it all, and it seems to be the issue I am having.
    I posted a reply in that thread in hopes of a resolution

    basically, I need a way to either fully index the ost__search table manually, or just have it run on a cron over the weekend.

    thanks
  • I am guessing my solution for version 1.10 is the same for this thread as it was the exact same issue.


    so something got lost in our upgrade from OST 1.6RC to 1.8.12 for our system emails.
    This carried over to our upgrade to 1.10 a few days later.

    Went to Admin Panel -> Emails

    Click on Diagnostic Menu
    ran the diagnostic for our 2 system emails, one of them just stayed hung up on "LOADING" for about 5 minutes before I closed it. This was similar to the issue we were encountering with out system.

    went to Admin Panel -> Emails -> emails
    click on the 2 emails we have setup and re entered all settings including the passwords.

    Re ran diagnostic, both ran without issues.
    Tested with a couple test tickets, and with 3 of our departments.
    all seems well now.

    this thread can be set to resolved
This discussion has been closed.