5.7 very slow to respond

I just upgraded to 5.7 from 5.3. I have the CommitCRM sql database installed along with 8 users. Since the upgrade, CommitCRM is dreadfully slow. When it loads, and a user clicks on tickets, it takes at least 20-40 seconds before the tickets show up. Try to print, it takes 30 seconds for the print dialogue box to come up. Some of the time the software reverts to "Not Responding". The 5.3 ran fast and was perfect. We just upgraded following instructions provided. Same server, same everything. Any ideas?

chumbert, this is not typical and actually all new releases been optimized and should end up working even faster...
My guess is that something with the Anti-Virus program has affect this. For example, maybe you've white-listed the entire RangerMSP folder tree before but now with all new executable files it scans it again...
In your Anti-Virus/security program please white-list the entire folder tree including all files and folders from being scanned. This should be the case both on the server side as well as on All client PCs. Then, restart everything, including server side services and try again.

HTH

So, I have taken the anti virus software off the server, I installed Windows 7 on a virtual machine and get the same result. Funny thing is that I have 2 licenses for CommitCRM. The fresh installation on a different server, runs great. The upgrade is hanging all the time! I do have about 15,000 tickets on the old installation... could that be part of the problem? Any other ideas?

There should be no problem with 15,000 tickets. We have customers with much more tickets and all work flawlessly just as it has for you until recently.

Please try to set the desktop shortcut you have for RangerMSP on each click PC to use a fixed IP address path instead of a server name (or mapped drive) and see if that helps. This will bypass most (though not all) DNS translation related issues.

we have tried everything suggested, but still have the hanging problem. Let me be a bit more specific.... when a user logs in, CommitCRM loads fast and all the accounts load fast. When we click on "tickets" on the left, it can take anywhere from 20-40 seconds to load the tickets (a lot of times CommitCRM goes to "not responding". Also, if I click on one of the "ticket status" options like "completed", it freezes again.

The other problem is that it hangs when we try to print. Any other ideas?

Thank you for the update. We're not sure exactly what's wrong and at least happy to learn that things do load fast, anyway, please use the Help > Technical Support menu in RangerMSP to send us your RangerMSP log files for analysis.

We aren't using/don't have the SQL database, and we have had the same problem with tickets since the 5.7 upgrade: Tickets take a VERY long time to for the Tickets window to populate when first opened; individual tickets take a long time to open, and ticket creation is a very long wait until the populated ticket appears (the busy curser is visible during these wait times). The wait times seem to be getting longer and longer as time goes on as well. My admins are already complaining, and soon the program will be so slow that we'll need to find a new solution. I'd be very surprised in Chumbert and we are the only ones experiencing this issue. We need a resolution, and we need it fast. I have sent out logs to you just now. Thanks for you help with this.

Log files have just been received and we will carefully analyze them. Thank you.

I have tried to send the log files from multiple workstations and get an error each time.

Failed sending Email

The server is not available. Contact your administrator is this condition persists.
ErrorCode: -2147221231

And I have the same problem as bdbrower, my techs are ready to kill me for upgrading.

Is it possible the solution is to do a backup and clean install?

Please zip folder <server>\RangerMSP\Logs and send it to us by email. In the same time send us an email without an attachment telling us that you've sent it.

Thanks.

mail sent yesterday. if you like we can give you remote access to one of our terminals to see the delays, Thanks

Logs received and will carefully be analyzed. Thank you.

You've had my logs for a week and I haven't heard back from anyone. Can you give me an update on the status your analysis please?

I'm checking the status with the technical team, will let you as soon an I have something.

Sheli

Here's an update - we may found the cause for this under some configuration and are already looking on ways to bypass it.

Thanks,
Sheli

Looking forward to the fix since it is now taking about 40 seconds for a new ticket to generate.

do we have any news on this yet? It is really slowing us down!

Nothing new here. As already mentioned, we found what may cause this (for <%1 of our users). We've already started to work on this and I it will be a part of our next release.

Most likely the original suggestions listed above, like white-listing RangerMSP folder tree in your Anti-Virus on All PCs and All servers, may help. We also recommend (in such cases) trying to run RangerMSP with a direct IP based shortcut and not a UNC one in order to bypass some possible naming resolutions delays.

In any case a solution for what we've found will be included in our next release, no ETA is currently available. We will post more when we have the details.

Thanks,
Dina

Ok so let me make sure I understand this. I purchased this software from you which you promote right on your home page as having free support included. You have verified a bug in the software which is dramatically slowing the functionality of the software in our installation, slowing the productivity of my staff, and creating the impression with our customers that we are not using professional software in running OUR IT BUSINESS (because they have to wait, with us, for over 60 seconds for a ticket to generate) and you are not willing to provide a fix until the next release, for which you cannot even provide a release date for. Have I missed anything here?

This is unacceptable. This is not the kind of support expected from a company of integrity and one that claims to "take care of their customers". The proper functioning of YOUR software is YOUR responsbility. It should make absolutely no difference whether this issue affects all customers or only one (your message is: "Individual customer problems aren't important to us"). You are aware of the problem and you apparently have a solution (or you are working on one); providing that solution to any and every customer experiencing this problem as quickly as possible should be be a priority, not something that has to wait until some future date-unknown release.

This is NOT a minor issue. Despite our following all of the suggestions you listed, the delay has increased from 40 seconds to 60 seconds just in the last FOUR DAYS! If this rate of increased delay continues then the software will be unusable with a few weeks. If your company can't support your own product (and your INDIVIDUAL customers) we'll consider that a failure of your commitment to provide free support with this purchased product.

One last thing, why do "chumbert" or I have to initiate every communication regarding this issue. Why aren't you informing us of the status of this issue before we have to ask about it?

bdbrower,

We feel your pain and are doing our best to help and therefore we're not really sure where this came out from and where do you take all this negative attitude from. We believe that it is completely not the right way to approach this nor does it reflect anything in what we do.

Don't take it personally, we know you are professional in what you do. Problems happens under all IT configurations, including our very own systems, our very own local network and very possible your network too. Not necessary wrong things, maybe conflicting things that affect.

In any case - what we're working on to fix has nothing to do with what you just described.

A decrease in 50% performance in 4 days. Sorry. I do recommend that you check things at your end that very same way we have been doing so far on our side (and have found something thanks to you help).

Thank you.

Please don't tell me you "feel my pain" until your staff becomes less productive and more frustrated every day because software that you rely on to operate you business has a bug that the software vendor won't provide a fix for until the next time the program is updated (with no release date available).

So you think I am out of line and should not react negatively to your not providing an immediate fix to a problem that you have identified as a bug in your software? You know we are a tech support company... we have a team of IT professionals here who have performed extensive troubleshooting in an attempt to identify a local problem and have found nothing in our systems the would cause this issue which started after we installed the last release. We have followed all of the suggestions in this thread and none have resolved the problem. You've indicated that your review of the logs we sent to you revealed the cause of the problem to be a "configuration issue" in the software.

By your own admission in this thread ("We may found the cause for this under some configuration and are already looking on ways to bypass it"; "We've already started to work on this and I it will be a part of our next release") the problem lies in your code, with a fix planned to be included in your next release of the software. My problem is with your not providing the fix to me as soon as it is available, instead of making me wait until the next release (which you cannot even provide a release date for).

If you had proprietary software that was central to the operation of your business and, after downloading a new release, a bug that created a long delay in a critical function of the software became apparent, I'm pretty sure you would have a "negative attitude" if that software vendor made you wait until the next software release for a fix (and gave you no idea when that might be). Especially if they sold the software with the commitment to provide free support. Try walking in my shoes before criticizing my approach to trying to get promised suppport for the software that is critical to the operation of my business.

And what do you mean by "what we're working on to fix has nothing to do with what you just described"? Are you working on the very specific problem detailed by "chumbert" and me in this thread or not? You've clearly indicated that you are.

I really don't think I am being unreasonable or being unduly "negative" in expecting you to provide the support you promised when I purchased this software. And yes, as the owner of my business, I take everything about it "personally". I also believe I have been as professional as possible in expecting CommitCRM to provide the professional level of support that I need. That means more than saying "Sorry" in reaction to the decreasing performance of YOUR software and telling me to check things at our end as if we haven't already done that mulitple times (starting before we first submitted this request for support).

If I'm not mistaken, there have been waits of up to 9 months or so between some releases (even recently). I cannot (and will not) wait anywhere near that long for a fix to this problem. Now do you understand my frustration?

We want to help, this is our job and this is what we are trying to do here, we always take responsibility and always happy when a solution can come from our direction (unlike asking you to do anything). We also do understand the frustration very well.

We do want to point out that:

1. Technically it's not a bug that we discovered and have started to work on. We wish it was a classic bug. We are trying to bypass a configuration which is outside of the scope of RangerMSP. Nevertheless, we are engaged to update our code and offer such a solution.

2. This issue might only affect a very small number of customers, and yes, we are aware that this does not help the ones it does affect :-( .

3. Once we will have the issue resolved and tested we will be able to tell more about when it'll become available.

Thank you and we apologize for the trouble it has been causing you.

We are watching this thread very closely as we are debating on whether to invest into the newest version of CommitCRM and Interlink or move onto the more robust (but more expensive) AutoDesk.

Commit: We are professionals, we work with software vendors/manufacturers on a weekly basis. We're used to receiving pat answers, blame shifting, or, in this case, opaque reasons for the problem.

Here's what I expect from the software manufacturer who I trust my business to run on:

Absolute, transparent honesty. When you say, "we found what may cause this (for <%1 of our users). We've already started to work on this and I it will be a part of our next release." it means that there is a bug in your software, or a conflict with certain configurations. There's no room for interpretation, if it's something you can "fix in the next release" then there's a bug. Period.

Maybe it's an issue between your software and your database vendor, maybe it's an issue with Server 2008 R2 Enterprise only when configured as a DNS server because it creates a conflict with XYZ module. Doesn't matter. What matters is that you're completely transparent about it, don't beat around the bush- be upfront and tell us what's going on. We're big boys and girls, we're smart, and we know when someone's not giving us the whole picture.

Because we do this for a living we also UNDERSTAND, we get that conflicts and bugs happen, and if you're open about what's going on we'll give you a lot of grace. Stone wall us and you'll receive just the opposite.

Lastly, and this comes down to a core, root issue at CommitCRM that has concerned me from the start. That's your software development, and now, bug/patch release management & planning, or complete lack thereof. Every successful software developer (I worked as a software PM for years) has a PLAN. They have milestones, deadlines and feature lists. They know exactly what's going into their next release, exactly when that release will be released and strive to meet those deadlines. Right now CommitCRM can't tell us when the next release will be out, what features will be in the next release, or what features won't be in the next release. Some days I wonder if the dev team just decides it's time to work and flips a coin over what to work on.

That venting and frustration aside I primarily wrote this to say: MAJOR SOFTWARE RELEASES ARE NOT PATCHES OR BUG FIXES. Why do you think Microsoft releases patch updates on a weekly basis, Intuit releases patches for both feature and bug fixes several times a month, and EVERY OTHER software vendor comes out with patches for their software on a regular basis. I have no clue why CommitCRM feels the need to roll every "patch/fix" into a 5.X release. Instead we should be seeing 5.7.0 released, then a month later when all the bugs come back a 5.7.X released to fix a list of problems. Releasing a patch is not an admission of guilt, software releases are never perfect, and never will be. So admit to the problems, release a patch for them, and move on.

Everyone -

A fix is already available.

It takes care of the issue we managed to find in the log files.

Please contact us directly to get the information on how to apply it to your system. When you do, please attach the following file to your email: \RangerMSP\Db\CmtVer.cmt.

Thank you.

The problem is solved for us with the update! Running as fast as ever. Thanks!

Great!!! Thank you for the update.

Looks like the problem on our system was solved by the fix as well. Thank you.

Great to hear. Thank you for the update.

What was the problem? What was the fix? Enquiring minds want to know.

The problem was something related to low level data access options that under some configurations resulted in slowness instead of a performance increase.

In any case, our engineers managed to find a good work around and I'm happy that it works well :-)

Dina

When I create a ticket, it whirs and clicks and flashes on the screen three or four times and then is ready to edit. It looks like a bunch of stuff in going on in the background, but it only takes about five seconds. Would a faster server improve this minor annoyance? I do have the Psuedo-SQL version. (Sorry for the PUN, but it ain't MSSQL or MYSQL)

Do you refer to when you click 'New' or when you click 'OK' to confirm adding the new Ticket?

Applied it and it made a huge difference for me. Techies now happy again.

It happens when I click OK

Attention "Exbabylon" - Thanks for your input to this thread. Whether or not it made a difference in a fix becoming available within a reasonable amount of time (instead of waiting for the next release) your sentiments were well spoken and reflected my thoughts exactly (and I suspect those of other users as well).

Although this incident was frustrating, I must say that other than the issues you addressed (which CommitCRM should take seriously) we have found the CommitCRM software to to be a very good fit for our needs at a very competitive price, and although limited to email support, in most cases tech support has been good.

Unless we encounter a problem with the software that cannot be resolved in a reasonable amount of time, we'll be sticking with CommitCRM and recommending it to anyone looking for a good IT CRM product at a very good value. That should not change as long as CommitCRM continues to focus on adding features that accomodate our continuing transistion to a more MSP/contract business model since we will primarily be serving those customers moving forward.

Thank you bdbrower. Much appreciated.

Thanks for the feedback "bdbrower", and to the CommitCRM team: You did a quick job of releasing a patch, but it would be nice to have more information (i.e. who should be asking for it) so you don't have customers who are frustrated powering through the problem rather than being able to self-help. I agree that there's a lot of value in the software, but that value doesn't matter if we don't trust and believe in the software enough to put every aspect of our company reliant on it.

@exbabylon, thanks for your feedback. The rule is simple - if you face very long delays when using the Tickets module then the patch may help, otherwise you can safely ignore it.

Helo CommitCRM Support,

I would like to have the fix for our CommitCRM CRM 5.7. Cuz I have the same issue with bdbrower.
Pls help me on this. My e-mail is jeff@clixph.com

Sent.