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

[resolved] v1.10 User sign in page atrociously slow

Having incredible slowness with users logging into our helpdesk site. The login.php script just hangs, sometimes for 2+ minutes before allowing the users in. Any suggestions or support would be very awesome! 

Comments

  • edited November 16
    You should post the information page of the dashboard from osticket.
    Are you using filters in osTicket? Did you modifiy osTicket?
    Check if there are errors in the osticket log or in the error log of the web server.
    Can you see high load or network traffic on the server.

    This information could be useful to help you.
  • Please help us to help you by reading and following the posting guidelines located in this thread: Please read before requesting assistance. The more information you give us the better we will be able to assist you. Thank you. 


  • mfelber,

    Thank you for your support. I apologize, I have attached a screenshot of what you guys are asking for. We are using zero filters in OSTicket, we are using filters in our Gmail account we are using for email fetching. Our install is not modified (beyond what the inherent web tools allows you to do).

    I may need some further assistance with any back-end server logs as this was all installed before me coming on board and I am trying to learn how to manage this and make edits/modifications/etc. 

    Appreciate all your help. 
    Capture.PNG
    1914 x 1476 - 179K
  • Are you utilizing any auth plugins?

    Is your Mysql DB on the same server as the webserver?

    What sort of load does your webserver have?  (and what hardware resources)

    Are you seeing any long execution mysql warnings?


  • edited November 16
    You need to check your Apache and PHP error logs as well to see if it's something in the code or something on the server that is causing this.

    Seems you're on Ubuntu so you can view your Apache logs like:
    $ cat /var/log/apache2/error.log | less

    (up/down arrows to move up and down | q button to quit)

    To view your PHP error logs you'll need to go to your php.ini file and see what's set for the 'error_log' setting. If there is a path set for that setting you'll basically run the exact same command as above just replace '/var/log/apache2/error.log' with the path from php.ini. If nothing is set or that setting is commented out then most of your errors are going to the Apache error logs.

    Hope this helps. Cheers.
  • Ntozier,

    We are using one plugin and it is the LDAP Authentication and lookup. [Attached]

    I believe the db is on the same server but am unsure.

    I do know that the ticketing system is running as a virtual machine on an Ubuntu 14.04 server. Any hints on the best way to reverse engineer this to help get you the answers you need? 
    Capture2.PNG
    1666 x 1455 - 165K
  • I use AD/LDAP and it do not experience that.

    Your screen shot has no LDAP servers specified.  You might want to fix that.
  • edited November 20
    All,

    Wanted to update you on what we discovered to hopefully help someone else in the future. Our issue seems to have stemmed from our DomainController. We were specifically having server time drift as we initially thought our NTP from our DHCP server (not running on our DC) was providing this time to clients, we learned that all clients are a slave to checking their DC for the correct time--which was never set up to look to the Internet for time. Once we resolved this we seem to be having a lot of healtier authentications, including OSTicket. 

    So If someone comes across this, please check with your DC first to see if anything weird is going on with the environment.


    Thanks again for everyone's time and support on this. I'm going to continue trying to reverse-engineer our environment so I can better understand it. 

    -Danny 
  • Thanks for letting us know what you found.

    Should I mark this as resolved and close it?  Or would you like it to stay open so you can update it if you find more?
  • ntozier,

    No problem. You can go ahead and close it. 

    Thank you, 
  • Very welcome. :)

    Please feel free to start another thread if you encounter more issues, have comments, etc. 
This discussion has been closed.