Jade D,

We have experienced similar although we were able to isolate ours to v17 using significantly more I/O and IOPS than v16 and previous versions. Where before on v16 we were pushing well under 200 IOPS with a Current Disk Queue Length of 1-3 seconds and a Disk Idle Time of 68% but under v17 we are looking at 350+ IOPS which causes a very high Current Disk Queue Length > 10-16  and our Disk Idle Time is never more than 1% (see https://www.smartertools.com/blog/2016/07/15-configure-perfmon-to-prevent-disk-issues). Our RAID Array just can't keep up with v17 and it causes significant issues (and note that we keep our Spam Filtering offloaded to multiple Incoming Gateways and still can't handle @ 35K emails a day for @ 1650 users on 275 domains).

We also saw a dramatic increase in CPU & MEMORY with v17 but were able to balance some of it out with tweaking some of the Indexing settings (which seems to use a lot more of both in v17, and I suspect is a significant part of the increased IOPS) and the other CPU & MEMORY issue with how it handles large Blacklists and SMTP Blocks (which granted was made better in a recent update but still not good enough to keep us from rolling back to a much earlier version of v17 that wasn't as adversely affected).

I keep hoping that as v17 matures the performance will get better but it seems that MAPI is the primary focus for SmarterTools at the moment. It may be a long while before performance in SmarterMail gets the full attention it still needs.

We too noticed performance issues with the webmail interface, but this happened since v16.

We've also experienced issues with slow IMAP syncing and EAS connections.

All of the above continued when we migrated to v17... however, the recent builds of v17 are much better. In fact, one of the chaps in the office said that the webmail speed is now back to that of v15!

The main performance issues we're seeing at the moment are CPU spikes and high bandwidth usage (for certain IMAP accounts), but we're working with ST to get these sorted.

Jade,

The current versions of SmarterMail performs significantly better than any other versions of SmarterMail.

Thats not to say, you may not be experiencing an issue but it would be more of an isolated problem which we would love to look into.  Please contact support and we can help you diagnose.

If your seeing delays in sending messages, it is often related to SPAM checks.  Most commonly RBL lists (which are DNS calls) can return results slow or even timeout which can backup a spool.  We have tools to help you review that within the interface.

Alex,

Regarding CPU spikes, current versions of SmarterMail can handle many more concurrent connections than previous versions. In the past, a user might have waited a fraction of a second for a response because it was queued but now they are being served along with 100's or 1000's of other users at the same time. This is GOOD thing!
 
Also, many customers look at the charts we provide in SmarterMail which is awesome.  They seen upwards trends in CPU and memory utilization but don't take into account how mail servers grow over time.  
 
For example, a mail server with the same exact number of users a year ago will see about 10% more activity than it did a year ago.  This is a combination of more SPAM and communication with other mail servers on the internet, increases in users' mailbox sizes, utilization of additional services with the mail product such as Team Workspaces, File Storage, etc.
 
We often get new customers asking us how they should architect their mail servers.  They know how many users they will be moving to that server immediatly.  We ask them what their growth in user count will be each year. We ask for approximations of the number of messages that will be sent. We then ask how many years they want that hardware to last without having to update it.
 
The reason we ask these questions is so that we can calculate based all our experience the average growth and utilization of a user year over year.
 
Hope this helps and if you have any specific questions or concerns, please contact support.  We would be happy to look into anything you see as suspicious or explain where your increase in activity is occurring.

Hi Tony,

Smartermail 17 does not perform better than 16, my statistics show this and 3/4 comments in this thread experience the same.

Are you able to share your metrics and recommendations for server configuration if you're seeing an increase in performance?

All of my servers are performing anywhere from 100% - 400% slower than previous versions.

My personal mailbox is virtually unsearchable, fortunately its on a domain that I no longer need to get access to that often so it doesnt affect me that much - how ever we have received a significant amount of complaints.

The smartermail admin interface is substantially slower.

Our monitoring server is whitelisted so none of the standard spam checks and RBL checks are performed on these monitoring emails, so those stats are as good as it gets for smartermail 17.

@Scarab, thanks for that link, I'll do some digging.

I'll be posting more stats and graphs later today.

Hi Jade, I noticed on your website you are using SolidCP as the control panel. We have noticed a bug in SolidCP 1.4.x whereby the SolidCP agent will hammer svcdomain.asmx (if I recall correctly) causing  the performance of the server to dip. Double check this is not the root cause.

Nathan, I appreciate you aiding a fellow customer and hope it solves their problem.

Jade, I understand there is a tendency to associate an issue we might see individually as a global problem but you are completely wrong if you believe current SmarterMail performs less than previous versions. That's not to say you're not having an issue. That's why I wanted you to contact support: so we could help you diagnose.

With regards to Alex, his server has been having troubles for a LONG time and much of it was because he was running a VM with inadequate hardware for his user base.  He is a perfect example of how the same number of users year over year add about 10% more utilization because of mailbox size and overall SPAM and mail traffic, and how issues outside of SmarterMail can affect a server's performance.

Hi Nathan

I'll take a look into that and see if it has any relevance, is that issue a solid v.1.4 + Smartermail 17 specific issue?

We've run solidcp for along time now and if the issue was prevalent in version 1.4.3 then we would have seen the same performance issues in smartermail 16, prior to the upgrade a month or so ago.

Or on the flip side, the Solid issue was there but better code in version 16 meant less of an impact on overall performance of all services.

Tony, my stats are showing the complete opposite of what you are claiming. What metrics are you using to monitor performance, have you tweaked your servers to run with similar or better performance to previous versions, are you testing in the real world, how are you monitoring and testing? Simply stating that your product is fast doesnt mean its fast, give me something to work with and back the statement.

The info I posted is factual, its data gathered from our monitoring and the logs dont lie.

Below are two screenshots of response times for POP services, clearly there is an issue, and you can see it starts immediately after upgrading.

I have two important tickets waiting at the moment and none of them are being attended to as your developers are busy with MAPI - so I doubt that logging a support ticket now will get anything resolved until MAPI is rolled out, and after that we'll have to wait for those bugs to be ironed out.

Alex's issue is very different to ours, we are running our smartermail servers on Enterprise Grade SuperMicro Servers with SSD's for OS, separate SSD's for the spool, separate SSD's for logging, separate enterprise grade hard drive for archiving, and separate Enterprise grade hard drive for mail files.

Each our servers are equipped with ECC ram + dual XEON E5 v4 CPU's.

I would entertain the idea that the performance we are seeing on our servers was isolated if 1 or 2 of these four servers were experiencing slow performance, but all four are behaving in the same manner.

Jade,

First, my name is Tim Uzzanti and I'm the CEO of SmarterTools.

Second, I don't doubt your having an issue but there are no known issues within SmarterMail that would cause the problem and would be something more unique to your environment.  I was replying to your post to understand your issue and Nathan was trying to give some feedback but you were providing generalities that SmarterMail is just slow.

Third, if your in need examples on how much faster current SmarterMail is compared to previous versions of SmarterMail.  For very large installations of SmarterMail v15 or v16 where startup time could had been 20 minutes now startup in 1 or 2 minutes.  If a server was able to pump out 1 million messages it would be more around 1.5 million messages.  In cases where disk I/o might have hovered around 60% utilization we were able to reduce it to around 30% utilization.

Providing POP response time is an indication of something but it could be anything.  For example, you could be having disk issues, network issues, bad nic driver, windows update, authentication problems, or a firewall change could be impacting things.  There could be tons of things that it could be.

These are PRTG reports but what do the reports in SmarterMail show and what else are you monitoring via PRTG.

Simple things like when you upgraded to SmarterMail 17.x would be a good start.

Do you have an ticket open on this issue or do you have tickets open on something else?

Hey Tim,

Apologies, Tony was handling an issue of ours and I was logged in to the support portal at the time of typing this response hence I upgraded his title to CEO.

I haven't submitted a ticket as of yet for this particular issue as I need to get my other two issues resolved first.

Once those are sorted we can tackle this as its going to take time from both sides to resolve.

We upgraded smartermail on 6/29/2019, this is explained in the first post and the graphs and stats that I provided reflect this.

What stats would you like to see from Smartermail?

What would you like to see from PRTG, we monitor quite a bit (CPU, Ram usage, Smartermail Service, POP, SMTP, Connected users via imap, pop and active smtp sessions, roundtrip, spoolcount etc)

No reported disk issues logged in the event viewer, hard drive sentinel enterprise reports all drives at over 98% (SSD's degrade faster than enterprise data center drives, hence the 98%)

There have been no updates to the nic drivers, no changes to firewall.

Hi Tim,

We're not running SM as a VM and I've never claimed this.

We started to experience issues on one of the last builds of SM 15. Then we upgraded to SM 16 and had to roll-back owing to the webmail and all services being pretty much unusable.

Problems we experienced were...

Nothing changed with our hardware and we didn't on-board any new clients or install any additional software/updates on our servers around the time the issues with SM 15 happened.

Obviously, we started to get calls from customers when the MailService.exe processed crashed. Then we were getting multiple calls a day from different clients reporting that the entire system was unusable (after upgrading to SM 16).

Again, nothing with our setup had changed.

Working with Rod, Tony and Kyle (from ST Support) we were able to get things under control.

Each build (either custom or public) delivered a fix or performance improvement. As previously mentioned, the very latest version of SM 17 has seen the web interface speed increase for us dramatically - it's like it was pre-SM 15 issues!

I can't remember the last time a customer complained to us about the speed of the mail servers now... this is certainly a good thing!

Hi Alex,

Your recent experience seems encouraging ! I mean "the very latest version of SM 17 has seen the web interface speed increase for us dramatically".

I had some similar issues. I still use SM15 waiting for experience feedbacks like this one.

Alain

Jade,

I asked Matt Petty to private message you earlier this week to discuss.  I think he is preparing a debug build for you but can review things related to this post as well.

Jade,

Noticed you haven't responded to some of our recent tickets and Matt said you haven't responded to his private message.  Did you get things working?

Howdy Tim, thanks for reaching out

I havent had a chance to reach out to any of the guys yet as we're busy a few server deployments at the moment. I just updated one of the tickets that we have open, but I'll PM Matt now

Thanks again