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

Looking to hire OSTicket expert to help with slow OSTicket install on Linux server

We are running OST v1.9.13 on a Linux cloud server.  Our system is up, fully configured, and stable , but it is VERY VERY slow at times.  Customer ticket creation can take up to 15 seconds to submit. When you click on the various tabs within OST it can sometimes take 5-8 seconds to load.  Searching for broad terms within the tickets will frequently crash our web sever. We are looking to hire someone to review our system and make the necessary changes in either OST or our Linux server (or recommend hardware changes) to get it working at max speed. Our budget is $250 for this one time job.  If you can provide this service please reply to this post.

Comments

  • Hey there,

    I know that you are looking to hire someone... but I have a couple questions and suggestions that may result in you not having to hire someone.

    First is upgrade!  1.9.13 is two versions behind current on the 1.9 tree, and 1.10 has been released.

    I find that slow downs opening a ticket are almost always related to mail being sent. So how do you have email configured?  PHPmail or SMTP?  If SMTP How far away from your webserver is the mail server?

    What is your server hardware?  Can you throw more processor speed and/or RAM at the problem?
    What are your software versions? (Apache, PHP, MySQL)
    Do you have MySQL Slow query logging turned on?
  • I'll leave the upgrade option alone for the moment because the 1.9x release notes dont seem to mention any performance issues being resolved. Also, I dont see any info about 1.10 in the wiki, not sure if I can upgrade from 1.9 or if its a totally new environment, we need to make sure our forms and front end still work perfectly.

    About the server config
    1. we are using SMTP for email.  Our web server is at 1and1 and our email is office 365. The latency between these two environment is very low so I dont think physical distance is an issue.
    2. Server logs show CPU, RAM and HD have plenty of headroom, in other words, the app does not seems to be maxed out at least from the info I see in my control panel
    3. Web Server is Apache, I dont see any version info in Plesk
    4. MySQL is 5.5.48
    6. PHP is 5.6.27
    7. I dont know if mySQL slow query logging is on, in fact I looked in phpMyAdmin and Plesk and I dont see any mention of MySQL Slow Query Logging. I need some direction on that one.
  • You can upgrade from 1.9.x to 1.10.  I have several times to test out the installer.  I usually clone my live site and do the upgrade on the clone to ensure that things work right prior to doing it on the live site.

    You are not the first person to mention slowness with Office 365 btw.
    https://github.com/osTicket/osTicket/issues/2752

    Are you using TLS/SSL to send mail via Office 365?

    Also as a side note (I know nothing about this other than it is offered) osticket.com offers Commercial Support.
    http://osticket.com/commercial-support

  • still digging.  I attached two screenshot from phpmyadmin showing all the Alert Values in MySQL and recommended settings. Be advised this is for our overall MySQL environment which is hosting 5 other databases, so I'm not sure which of these alerts are for OST and which are for other apps we are running.  If anything in these logs may in fact be the issues, please let me know and I will be happy to try and change.
    screen1.png
    1534 x 769 - 132K
    scren.png
    1480 x 709 - 117K
  • ntozier,
    There is no setting for TLS/SSL in Sending Email via SMTP.  it just has host name, port number, and authentication required.  Above that in the Fetching Email section it does say IMAP + SSL.  Not sure if I am answering your question, I dont see TLS/SSL anywhere on the Email Screen

    I honestly dont think this is an email issue because of two factors.
    1. when I am in Open tickets and I click on the Closed Tickets tab the system takes 10 seconds to finally display the closed tickets.  this has nothing to do with email 
    2. when I search in OST for anything with a space for example "john smith" OST crashes my web sever and I need to wait 5-6 min before it comes back online.

    I believe this is either a PHP or a SQL issue, unfortunately, my knowledge is somewhat limited in order to a deep review which is why I am asking for help from an expert.  

  • Correct there is no specific settings, but to use ssl for sending you would prefix the host with ssl:// and use the appropriate port.

    From your screen shots the my.cnf file directive long_query_time is set to 10s.  So it will only log queries that take 10s or more. and slow query log is disabled.  If you enable it and lower the time to 5s it may catching whats taking you 6+ seconds.  You can try to enable that in the config file.

    Do you have a virtual server environment [or a desktop] tht you can play with?  You can install apache/php/mysql [same versions]  and osticket on it and supply the same osTicket settings and see if you can replicate the behavior.  This should tell us if its the server your on now or something else.  Then we can do things like play with changing the PHP version, PHP configuration settings, and not worry about adversely affecting the production envioronment.
  • We are on a virtual server. Unfortunately, I dont have the time to setup another environment. I dont think the issue is email, I'm 90% certain it is something with mysql or my php settings, probably a cache or memory setting. Someone also suggested APC but i have no idea what that is.  Hopefully someone out there wants to make a few bucks to help me out, otherwise I am waiting to hear back from the commercial support people at OST .

  • i was able to enable the mysql slow query.  It looks like there are tables without indexes setup correctly.  Search queries are the longest taking 3-5 minutes and searching millions of rows.. something is not right.

    Here is a sample search querey

    # User@Host: osticket[osticket] @ localhost []
    # Query_time: 441.020223  Lock_time: 0.000302 Rows_sent: 500  Rows_examined: 2755495585
    SET timestamp=1478572296;
    SELECT DISTINCT COALESCE(B1.ticket_id, B2.ticket_id, B3.ticket_id, B4.ticket_id) FROM (
                    SELECT object_type, object_id, MATCH (search.title, search.content) AGAINST ('mark smith' IN BOOLEAN MODE) AS `relevance`
                    FROM `ost__search` `search`
                    WHERE MATCH (search.title, search.content) AGAINST ('mark smith' IN BOOLEAN MODE)
                ) `search` LEFT JOIN (select ticket_id as ticket_id from ost_ticket
                ) B1 ON (B1.ticket_id = search.object_id and search.object_type = 'T') LEFT JOIN (select A2.id as thread_id, A1.ticket_id from ost_ticket A1
                    join ost_ticket_thread A2 on (A1.ticket_id = A2.ticket_id)
                ) B2 ON (B2.thread_id = search.object_id and search.object_type = 'H') LEFT JOIN (select A3.id as user_id, A1.ticket_id from ost_user A3
                    join ost_ticket A1 on (A1.user_id = A3.id)
                ) B3 ON (B3.user_id = search.object_id and search.object_type = 'U') LEFT JOIN (select A4.id as org_id, A1.ticket_id from ost_organization A4
                    join ost_user A3 on (A3.org_id = A4.id) join ost_ticket A1 on (A1.user_id = A3.id)
                ) B4 ON (B4.org_id = search.object_id and search.object_type = 'O') LEFT JOIN ost_ticket A1 ON (A1.ticket_id = COALESCE(B1.ticket_id, B2.ticket_id, B3.ticket_id, B4.ticket_id)) LEFT JOIN ost_ticket_status A2 ON (A1.status_id = A2.id) WHERE ((A1.staff_id=17 AND A2.state="open") OR A1.dept_id IN (1,7,8))ORDER BY `search`.`relevance` LIMIT 500;

    you can see at the top the query time listed is 441 seconds
    the lock time was extremely low as well

    any idea how we can fix this.. is there a script we can run to re-index the tables?
  • I confirm I have exactly the same problem in 1.9.4.
    16,498 tickets in bdd for 197,975 threads (ie : table ost_ticket_thread).

    SQL Example when problem occurs :
    SELECT DISTINCT COALESCE(B1.ticket_id, B2.ticket_id, B3.ticket_id, B4.ticket_id)
    FROM (
    SELECT object_type, object_id, MATCH (search.title, search.content) AGAINST ('mysearch' IN BOOLEAN MODE) AS `relevance`
    FROM `ost__search` `search`
    WHERE MATCH (search.title, search.content) AGAINST ('mysearch' IN BOOLEAN MODE)
    ) `search`
    LEFT JOIN (
    select ticket_id as ticket_id from ost_ticket
    ) B1 ON (B1.ticket_id = search.object_id and search.object_type = 'T')
    LEFT JOIN (
    select A2.id as thread_id, A1.ticket_id from ost_ticket A1
    join ost_ticket_thread A2 on (A1.ticket_id = A2.ticket_id)
    ) B2 ON (B2.thread_id = search.object_id and search.object_type = 'H')
    LEFT JOIN (
    select A3.id as user_id, A1.ticket_id from ost_user A3
    join ost_ticket A1 on (A1.user_id = A3.id)
    ) B3 ON (B3.user_id = search.object_id and search.object_type = 'U')
    LEFT JOIN (
    select A4.id as org_id, A1.ticket_id from ost_organization A4
    join ost_user A3 on (A3.org_id = A4.id) join ost_ticket A1 on (A1.user_id = A3.id)
    ) B4 ON (B4.org_id = search.object_id and search.object_type = 'O')
    LEFT JOIN ost_ticket A1 ON (A1.ticket_id = COALESCE(B1.ticket_id, B2.ticket_id, B3.ticket_id, B4.ticket_id))
    LEFT JOIN ost_ticket_status A2 ON (A1.status_id = A2.id)


    WHERE ((A1.staff_id=16 AND A2.state="open") OR A1.dept_id IN (4,5,21) OR A1.team_id IN (3,5) AND A2.state="open")
    ORDER BY `search`.`relevance` LIMIT 500

    FYI this query return :
    500 rows in set (3 min 5.04 sec)

    Nb : I am not forced to use space in the search to reproduce it
    NB2 : Sometime search seem fine --> When data allredy cached by mysql I presume

    I will try to upgrade it to 1.10 in few day on a lab (it a vm, i can snapshot it) and feedback in this thread
  • HI,

    I had just tested the upgrade from 1.9.4 to 1.10.
    This solve the performance issue for us

  • We did install v1.10 and tested it for a couple of hours.  I loved how the movement between tabs and tickets was really fast, but we were disappointed to see the dreaded Save Draft error was still there and also the app crashed several times as we moved through the various workflows. We did not move our entire database so I cannot comment on whether or not search is fixed.  Given the few issues we saw so quickly, we'll probably give v1.10 a few more months to stabilize. For now I guess we need to deal with the shortcomings of v1.9.15 since most recommendations in the help threads involve upgrading to v1.10 rather than trying to fix v1.9.15.   
  • I'd be interested in hearing more about this: "app crashed several times". I haven't experienced anything that I would categorize as an "app crash" on my 1.10 test box. Which version of 1.10 did you install?
Sign In or Register to comment.