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

Slow page loads when agents view tickets

Howdy,

We have been using
Osticket for the last three months on a Ubuntu vm, recently we have
ran into an issue where the page load time for agents viewing tickets
now takes between 15-20 seconds to load vs the average 2 seconds that
everything else in Osticket takes to load. We have just upgraded to
v1.9.9-1 in hopes of resolving this; but still the load time for
viewing tickets remains the same.

I'm assuming this
has something to do with mysql & have enabled mysql slow logging
and below is the output of the log when a ticket is clicked on.





# Time: 150718
23:21:50



# User@Host:
osticket[osticket] @ localhost []



# Query_time:
0.000941 Lock_time: 0.000127 Rows_sent: 2 Rows_examined: 183



SET
timestamp=1437276110;



SELECT 'open',
count( ticket.ticket_id ) AS tickets FROM ost_ticket ticket INNER
JOIN ost_ticket_status status




ON (ticket.status_id=status.id




AND status.state='open') LEFT JOIN ost_ticket_collaborator
collab




ON (collab.ticket_id=ticket.ticket_id




AND collab.user_id = 528 ) WHERE ticket.user_id = 528 OR
collab.user_id = 528 UNION SELECT 'closed', count( ticket.ticket_id )
AS tickets FROM ost_ticket ticket INNER JOIN ost_ticket_status status




ON (ticket.status_id=status.id




AND status.state='closed' ) LEFT JOIN ost_ticket_collaborator
collab




ON (collab.ticket_id=ticket.ticket_id




AND collab.user_id = 528 ) WHERE ticket.user_id = 528 OR
collab.user_id = 528;



# User@Host:
osticket[osticket] @ localhost []



# Query_time:
0.000156 Lock_time: 0.000038 Rows_sent: 3 Rows_examined: 6



SET
timestamp=1437276110;



SELECT canned_id,
title FROM ost_canned_response WHERE isenabled AND (dept_id=5 OR
dept_id=0) ORDER BY title;



# User@Host:
osticket[osticket] @ localhost []



# Query_time:
0.000169 Lock_time: 0.000043 Rows_sent: 4 Rows_examined: 12



SET
timestamp=1437276110;



SELECT s.staff_id,
s.firstname, s.lastname FROM ost_staff s INNER JOIN ost_groups g
ON(g.group_id=s.group_id AND g.group_enabled=1) WHERE s.isactive=1
AND s.onvacation=0 ORDER BY s.firstname, s.lastname;



# Time: 150718
23:21:52



# User@Host:
osticket[osticket] @ localhost []



# Query_time:
0.000053 Lock_time: 0.000024 Rows_sent: 0 Rows_examined: 1



SET
timestamp=1437276112;



DELETE FROM
ost_ticket_lock WHERE expire<NOW();



# User@Host:
osticket[osticket] @ localhost []



# Query_time:
0.000118 Lock_time: 0.000045 Rows_sent: 0 Rows_examined: 3



SET
timestamp=1437276112;



SELECT email_id,
mail_errors FROM ost_email WHERE mail_active=1 AND (mail_errors<=5
OR (TIME_TO_SEC(TIMEDIFF(NOW(), mail_lasterror))>600) ) AND
(mail_lastfetch IS NULL OR TIME_TO_SEC(TIMEDIFF(NOW(),
mail_lastfetch))>mail_fetchfreq*60) ORDER BY mail_lastfetch ASC;



# Time: 150718
23:21:53



# User@Host:
osticket[osticket] @ localhost []



# Query_time:
0.000272 Lock_time: 0.000036 Rows_sent: 0 Rows_examined: 391



SET
timestamp=1437276113;



SELECT id FROM
ost_draft WHERE `namespace`='ticket.response.187' AND staff_id=2;



# User@Host:
osticket[osticket] @ localhost []



# Query_time:
0.000278 Lock_time: 0.000032 Rows_sent: 0 Rows_examined: 391



SET
timestamp=1437276113;



SELECT id FROM
ost_draft WHERE `namespace`='ticket.note.187' AND staff_id=2;



Mysqltuner
recommended running optimize table which has also been done. Any
help with this would be greatly appreciated.






Thanks,



-Tim 

Tagged:

Comments

  • pinging the devs to take a look at this.
    I think that they have been focusing on MariaDB so that might be part of the slowness problem.
  • any other thoughts from anyone else? It's not a client facing issue so the impact is small but for our staff it's a bit of a nuisance. Any help would be greatly appreciated.
  • Old thread, but in case someone else stumbles upon it:

    I had the same problem and could not find a solution. After some debugging it came down to the "is_email" function in class.validator.php which checks if the email address of the client is valid. Part of this function checks if the domain has a MX, A or AAAA record. 
    My problem was that our ISP had decommissioned the DNS server which was first in our resolv.conf. The function was thus timing out on this server and taking 5s longer than it should have.

    TLDR:
    If you have the same problem check your DNS resolvers.
Sign In or Register to comment.