Admin/Item Tracking Projects very slow
Moderator: SourceGear
Admin/Item Tracking Projects very slow
When accessing this area of the web interface function is very slow. It take 15 to 30 seconds for the request site to respond no matter what function is being executed. It is only in this area of the site though. The source control admin interface performs fine.
In the previous version I had reported a stored procedure that was taking a very long time to execute by no one ever responded to my email.
In the previous version I had reported a stored procedure that was taking a very long time to execute by no one ever responded to my email.
Do any errors pop up in your Fortress server log when you are accessing that portion? That is located in C:\Windows\temp on the server.
What about in your server's Event Viewer log?
Do all other users experience this slowness?
Do you have access to the SQL database? If so, can you give the sizes of the following files?
sgvault.mdf
sgvault_log.ldf
sgmaster.mdf
sgmaster_log.ldf
sgdragnet.mdf
sgdragnet_log.ldf
As far as the email response, I do know we try to reply to every single email. If you could send a new one to support at sourcegear.com, I can run a search based on your email address and try to track down what happened there. It may have been filtered as spam on either our end or your end possibly.
What about in your server's Event Viewer log?
Do all other users experience this slowness?
Do you have access to the SQL database? If so, can you give the sizes of the following files?
sgvault.mdf
sgvault_log.ldf
sgmaster.mdf
sgmaster_log.ldf
sgdragnet.mdf
sgdragnet_log.ldf
As far as the email response, I do know we try to reply to every single email. If you could send a new one to support at sourcegear.com, I can run a search based on your email address and try to track down what happened there. It may have been filtered as spam on either our end or your end possibly.
No errors it just takes a VERY long time to respond. I did a SQL trace and there were no database calls that took a long time to execute. Here are the database sizes.
sgdragnet.mdf 70,451,200
sgdragnet_log.LDF 16,973,824
sgmaster.mdf 2,228,224
sgmaster_log.LDF 3,932,160
sgvault.mdf 7,443,251,200
sgvault_log.LDF 1,373,896,704
We had a DNS name resolution problem on this server and I noticed that when I accessed the site using the DNS name that any attempt to access the admin functions on the Item Tracking menu would always throw and exception because the DNS name couldn't be resolved (this has since been fixed). Accessing the site via it's IP address worked fine. So, now that I see that there is no database performance issue and the CPU usage on the web server itself is not a problem, I wonder if the attempt by the code to make an HTTP request to itself is the problem.
sgdragnet.mdf 70,451,200
sgdragnet_log.LDF 16,973,824
sgmaster.mdf 2,228,224
sgmaster_log.LDF 3,932,160
sgvault.mdf 7,443,251,200
sgvault_log.LDF 1,373,896,704
We had a DNS name resolution problem on this server and I noticed that when I accessed the site using the DNS name that any attempt to access the admin functions on the Item Tracking menu would always throw and exception because the DNS name couldn't be resolved (this has since been fixed). Accessing the site via it's IP address worked fine. So, now that I see that there is no database performance issue and the CPU usage on the web server itself is not a problem, I wonder if the attempt by the code to make an HTTP request to itself is the problem.