This project has moved and is read-only. For the latest updates, please go here.

The TicketDesk website is SLOW!

May 1, 2009 at 3:46 PM
Edited May 1, 2009 at 10:10 PM
I just installed TicketDesk, and I really like it, but it is very very slow.  All the other website applications I have running on this machine are fine.  It takes 25-30 seconds to login.  Any idea what could be causing this?

Pentium D 3GHz
2GB Ram
Windows 2003
SQL Express 2005
TicketDesk 1.2.2
AD Integration

Server is also acting as file server, and hosts other intranet applications.  Company is only 50 users in size, and no more that 2-4 people max accessing the Intranet at the same time.  Task manager looks okay,  SQL service gets up 10-15 when data requested, but only for a sec or two.

One thought that I had was that maybe it has to do with authentication.  I have one domain controller in Sydney, AUS.  I am in PA, USA.  I know that accessing the domain controller in Sydney is very slow.  Is there are way to specify which domain controller you want the integration to work with?
May 4, 2009 at 4:24 AM
The odds are good that the problem is AD. Even on a local network with low overhead and amazing servers AD performs like a dog. TicketDesk does a lot of internal caching to reduce the overhead somewhat, but there are still going to be initial calls to build user lists and get information about the users from AD when the application is first started up or when it has been idle long enough to unload.

While performance is noticably slower with AD, in normal situations with local domain controllers TicketDesk shouldn't be painfully slow... and performance after the first few pages have been loaded should pick up quite a bit as information is cached on the fly.    

A lot of the performance against AD depends on how AD is configured and what groups you tell TicketDesks to use. To maximize performance I suggest using AD groups that contain only the specific users that access TicketDesk rather than built-in groups. The build-in groups contain a lot of non-user accounts typically... service accounts, admin accounts, application accounts and there can be substantial cross group membership chains too. TicketDesk filters out a lot of this noise for you, but it still scans through every user in those groups, including users that belong to the group via another sub-group that is a member. 

In your case, a lot depends on how well configured your AD environment is. TicketDesk doesn't choose what controller it will talk to. It will use whatever domain controller the underlying OS is using. This can get complex. Normally, in a geographically dispursed environment you'd have all of the critical AD information replicated to the domain controllers at the local site and your server would always connect to the local site's controller.  This would perform decently well. But if your configuration doesn't have infromation ticketdesk asks for replicated locally, or if for some reason your host server is using a remote domain controller then performance will degrade from poor to abysmal. 

Mis-configured AD environments are a common problem though, and you may or may not have the ability or skillset necessary to hammer out the problem at the AD level.... which is too bad because your whole network will suffer if AD isn't right.

If you cannot resolve this at the AD level, you could always switch to using SQL security instead. The users would have to create accounts and login to access the system, but performance would not be an issue.