1 2 Previous Next 16 Replies Latest reply on Oct 25, 2010 2:25 AM by dmshimself

    Service Desk running extremely slowly


      Our installation of service desk (landesk IT business management console) runs extremely, frustratingly slowly!! nothing responds faster than 15 seconds, and sometimes you just have to have a cup of coffee. We expected much better performance from a client installation.


      Our database has around 4000 incidents (that would say, it's small). We have a handfull of users and a fantastic network.


      I am not looking for miracles here, but does anyone have any tips for debugging the situation. unsure if the problem is in the client, or the database. I have seen the product running much faster at larger installation sites.


      thanks for any comments!!



        • 1. Re: Service Desk running extremely slowly
          Julian Wigman ITSMMVPGroup



          There's a performamce tuning document in the documentation set somewhere so this should be your first port of call.


          Other areas IMHO would be the size of certain tables growing out of control:


          • tps_user_session
          • tps_user_message
          • tps_user_messgae_recipient


          Might be worth looking at size of these in SQL server.


          I happened to look at the tps_user_sessions table on one of my Dev systems a few months back to find basically 1.2 million rows of **** in there!  Suffice to say i now clear this down regularly.





          1 of 1 people found this helpful
          • 3. Re: Service Desk running extremely slowly

            The performance guide makes interesting reading and if you are running MS SQL use the bit on profiling your database and take the advice that automatic process offers.  Also use metadata caching on your clients, also mentioned in the guide.

            • 4. Re: Service Desk running extremely slowly



              I am not an super expert on operating systems but have som field experience as a partner to LANdesk from dealing with a different customer projects. The experience is that in some places  the LANDEsk Servicedesk system is fast and in other it is slow. The funny thing is that I can not connect this difference to underlying "power" of servers and networks or even the SQL envionment. It is often a combination that in the end causes pain. But there is almost in all cases an answer to solve the performance problem.  The trick is to find out where the "fix"is to find and what to recommend. 
              There are some things I have come accross!
              A tip is to look at the CPU speed of the applicationserver. As I see it CPU speed is important. The faster the cpu can "get rid" of requests the better. The application server has requests in the worker process ( IIS) which in turn comunicates with a SQL server environment.  My experience is that it is better with one fast cpu then 4 slow multiple cpu's.  But it is more a feeling than absolute knowledge.
              And if the virtual memory used by the operating system ( Windows) on the application server is greater then the phyical memory everything "stops".
              Do not run a Console on the application server if memory is an issue. It will take  from 100k- to 500k of memory and requests use of the CPU resource. 
              Another thing is if  the connection to the SQL server is slow or has to wait the the request to be processed.  A tip is to make sure that the connection from the applicationserver to the SQL server is clustered together and not uses the network to communicate. Another is that SQL server has its own virtualisation of memory. Does it have enough "physical" memory allocated to process  the majority requests with information already in the SQL memory.
              Sometimes Virtualisation tends to put to slow physical CPU power in the physical computer that runs the virtual VMware environment. There are more than one "logical" server that shares the power och the physical server. How is this power shared to the logical servers? And how is it set up? I heard from one installation that a logical Server got a slot of the physical server only when all 4 physical CPU's were free because the logical server was set up to use 4 cpu's . The way a logical server get access to the physical CPU in a virtual environment is important I beleive. I have experienced a big performance slowdown when moving from a physical server to a virtual environmentsin som cases.
              I have one example where my laptop runs faster with a VMware servers started in my laptop  than 3 64 bitsservers working together.
              64 bits and 32 bit environments working "with or against each other"in claiming resources from operating system in the same application server can also be a performance issue.
              Another thing is to look if You are using more than one worker process in IIS. How often do they get recycled?  Everytime they are recycled a new "caching" on the server takes place and demands communication to the SQL server.
              And changing the production systems metadata should be kept at a minimum. Every change ( query, windows, processes and so on ) demands updates i cache areas ( worker processes IIS) . If You are using many TPS application servers  all the environments has to be updated which causes performance issues.   
              I agree with Dave that the performance documentation is usefull. And take a good look at the hardware and software recommendations.
              • 5. Re: Service Desk running extremely slowly

                Goran - can you expand a bit more on the bit about not using the network to communicate to the SQL server?  Do you mean kep SQL Server on the same box as the TPS Server?

                • 6. Re: Service Desk running extremely slowly



                  I am told that SQL and Application are in the same "cluster" and does not use the "big" network to communicate. This means that there is a local switched network between these machines that work independently just for communication between these machines.


                  More information:






                  • 8. Re: Service Desk running extremely slowly

                    hi Julian,


                    thanks for your comments... i have looked in the tps_user_session table, and see i have close to 1 million records in there! when you say that you "clear them out", do you simply delete the whole bunch, or trancate older records. are there any side effects of removing this data? it must be stored for a reason?



                    • 9. Re: Service Desk running extremely slowly

                      thanks for all the replies here!


                      I have not come so far as to find a solution yet, but found the db server running way over its physical memory, and swapping like crazy... however rectifying this did not help my performance problems noticably will check all the suggested help further



                      • 10. Re: Service Desk running extremely slowly
                        Julian Wigman ITSMMVPGroup

                        I think this should be one that support answer "officially".





                        • 11. Re: Service Desk running extremely slowly

                          i found this in the performance guide


                          Archiving user session table entries

                          Every time a user logs in or a service polls an entry is added to the table tps_user_
                          session, which can therefore quickly fill. We recommend that you truncate this table
                          so it would seem it is MORE than ok to truncate, it is RECOMMENDED!
                          • 12. Re: Service Desk running extremely slowly
                            masterpetz ITSMMVPGroup

                            Hi Craig,


                            we had a similar problem of one of our customers. We have spend very much time of troubleshooting and tracing and finally found a very effective solution. incidents open now in 5 - 6 seconds, before it takes about 15 seconds.

                            Can you please try something on one of the affected clients, where the console is installed and slow. Navigate to the console.exe.config or console64.exe.config and add the following lines somewhere between




                            <generatePublisherEvidence enabled="false" />


                            Start the console and look, if the performance is better now. It would be nice if you can post the results.


                            Thanks and best regards


                            • 13. Re: Service Desk running extremely slowly



                              Have you got database tuning in place as this makes a huge difference.


                              Have a look at my link below, and ask your SQL DBAs to schedule the attachment in the post to run nightly.





                              • 14. Re: Service Desk running extremely slowly

                                Christian - I've not seen that one before and it doesn't seem to be in the performance guide.  Can you give any background as to what it does and any side effects?



                                1 2 Previous Next