I opened a ticket on this and it is being looked at.

 

1,180KB? That's one megabyte, not one gigabyte (I had to read your post again to be sure). Not a very large file here in the 21st century. As you've said, doesn't look as if this should be the cause of the delays you're talking about. Either way, it seems to need some attention on the programming side.

Just thought of this: You can try having the user keep the calendar open in another browser tab or a different browser session entirely.  This way it only needs to load once. Takes a little bit of getting used to, but it may help the situation; wouldn't help much for updating, I know, but still.

Update on this issue: My client contacted me today and clarified their concerns. While the speed of update in the calendar is ugly, it can be somewhat dealt with my staying in the week display mode. What has not been resolved is the lack of invitations from the version 14 shared calendar. This is ramping up to be a deal breaker. We are currently looking at scheduling downtime for a complete downgrade to version 11 to address this specific issue. I'm trying to avoid that as the issue is supposed to be in front of the developers, but in reading through the threads here it appears there are a lot if issues more critical before the developers right now. My client uses the webmail exclusively on computers and has generally been happy with it. I've considered looking at Outlook as a client to get around the calendar issue but now I am reconsidering that based on the problems reported on that front. I understand it is affecting only a small number but I know my luck. My client would be one of those affected. They have a cloud over them and can imagine a problem if given enough time. Version 11 worked in most respects so that may be safest for me.

 

The thing I have been trying to figure out is how I can test a new version under similar load and configuration for my client before deploying it. There are licensing issues, as well as port conflicts to be dealt with. How are others dealing with testing a new version prior to deployment?

I am hoping for a fix to this problem as well.  SM Version 11 has been working wonderfully for one client of mine; the only real issue being occasional disconnection of the webmail client (even directly on the same LAN as the mail server), but most users have been set up for one-click login to webmail while in-office, so it's no big deal. This installation uses Symantec email security.cloud for external spam filtering, so that overhead is eliminated - both in greatly reduced incoming email volume and server processing time.  And NOBODY uses Outlook (yay).

 

Since ST is (rightfully) promoting the use of their webmail client, the calendar issue is a biggy. When this is resolved - OK and a few other things - the customer just might move to v15 (or greater).

 

I have precisely the same issue, also with a shared calendar although my users file is 14MB - still not that big.

 

They had no problems with it when they were running version 5.x (yes I meant 5.x), it worked fine for them in that version but now they're using v 14.6 they have really slooowwwww speeds.

 

Over 65 seconds to save a new appointment!

 

I've uninstalled and reinstalled, deleted and recreated index files etc. but to no avail. Users who have an empty calendar have no issues saving new appointments.

 

I too think I'll have to go down the support ticket route, but doesn't sound like I'll get a resolution soon.

 

Poor users are pulling their hair out and I can understand why.

 

Quite a serious issue.  If you do open a ticket, would you kindly let us know if anything comes of it? Thank you.

I have a ticket open on both of the issues I mentioned in the original post. I am now testing a patch for the invitations issue and should have some confidence in the solution soon. I was told they are now looking into the speed issue. I provided them with the calendar files that were causing the issue so they can replicate it.

 

As an interim fix, I did go into the shared calendar xml file and deleted all of the old appointments. I made a copy of the file so I can past them back in when they have the problem resolved. The monthly calendar updates much faster now, though still not as fast as we were used to in version 11. Most of the users at my client now operate in the weekly calendar mode which is much faster.

Thanks, Simon and Mark. These issues have been reported for some time now, and ST has been a bit quiet on this. 

I can't do that kind of fix (even temporary) here. Folks would be quite miffed if they couldn't have all their old calendar data in the same place as the current data. Heck, it would even bother me, big time. Hoping for a real fix here.

Simon, the fix came from ST and it is actually a later test build. My client is still beating it up but I am hoping to get some good word from them today as to whether they could break it.

 

Paul, I agree with you. The exception is my client and the apparent fact they don't use or care about past appointments at this time so it allowed me to do the experiment. In my place of business past appointments and invitations are important records.

 

I'm hoping it won't be too long before there is a resolution. I don't know if this has been brought to the attention of the developers before. It may have been discussed here or with some support folks but I have found if it doesn't reach the developers there isn't much chance of a resolution. In truth, SmarterTools is only the third company I've worked with in my career of 30+ years where the developers took an interest, much less actually worked on a problem I have reported. Cisco was the best at it. For some reason my Cisco DSL aggregation router found three different bugs in the code. Cisco support was phenomenal back then, and when they confirmed it wasn't working as expected a developer was quickly pulled onto the ticket.

 

... I have also asked for an update on the speed issue ...

 

I've got an update to test this evening on the speed issue. I will let you know the results ASAP. I actually got the update last week but have been out on vacation. Sorry for the delay.

I installed the custom build provided by SmarterTools and did see a significant performance improvement. I edited my shared calendar xml file to add back in the appointments I had removed, taking the file back up to 1,223 KB. The screen refreshes when changing between weekly and monthly views is now 3 seconds for both. Before installing the new build the monthly view took 15 or more seconds to update. An added improvement is the busy bar now appears when the new view is loading, where the previous builds had nothing indicating the system was processing the view change at all.

 

We will be running more tests in the morning, such as adding appointments in the monthly view. That was very tedious before. I will also be reporting to support and the developers in a few minutes. 

 

I'm sorry to hear Simon didn't have similar results. Not sure what may be going on there.

**  I suggested they started by looking at v5.x because that managed a file of that size perfectly well when they are using that version earlier this year. **  (Simon Collingridge)

 

 

 

 

I think it is HIGHLY unlikely SmarterTools will go back and look at version 5 code. There will be so few similarities, and the programming tools and libraries will have changed so much that comparison would likely yield dubious results. A more valuable metric would be to determine at what recent major version upgrade the problem occurred. I noticed it when moving from version 11.x to 14.x. I don't have a spare machine I can load up server versions on to test this, nor do I have a big enough calendar file to make the issue obvious for me. It would be MUCH more helpful to identify if the problem occured at version 12 or whatever.

 

If course you are right, Mark. My point is that in regard to this problem, SM is regressing; this is in my opinion an issue of some magnitude, that needs to be resolved quickly. The lack of response by ST is disconcerting.

I am watching this thread with great interest. Hoping for some good news from ST.
 

I am cross-referencing another thread (in which I've cross-referenced this thread as well)...

 

https://portal.smartertools.com/community/a87905/contacts-and-calendar-problem-mailservice_exe-eating-ram-and-cpu.aspx