我们的业务每周都会向大量订阅者发送简报.当业务非常年轻时,在我加入之前,他们使用了一个"免费"版本的一些群发邮件,花了六个小时发送5K邮件,并且在互联网上的每次反向DNS检查都被违反了.
我将其升级为定制的.Net小部件,该小部件在正确的服务器上运行,并且可以在半小时内发送最多约20k的邮件,并且完全符合DNS.不幸的是(或者幸运的是,取决于你的立场)我们的邮件列表现在已经超出了这个简单的工具.特别是它缺乏足够的节流,它可以制作比服务器可以舒适地立即发送更多的邮件.我需要实际监视IIS SMTP服务器的可用外发邮件存储分配的完整程度,并相应地限制负载.
不幸的是,我找不到邮件对象在转换成邮件时(或者甚至)转到的位置的信息.如果我有一个值得关注的地方,我可以实现一个filesystemwatcher,目前我没有.如果没有创建实际的邮件文件,我想我将不得不创建一个来实现该功能,但我需要知道在哪里放置它.允许系统以某种方式确认发送也会更令人放心,但我不知道如何从系统中检索已发送邮件的数据.
广泛的谷歌搜索在这些方面已经证明是模糊的; 所以我想知道这里是否有人知道我可以在哪里获得这些问题的指南,或者可以指出我正确的方向.
非常感谢.
编辑:最后我放弃了尝试测量IIS SMTP服务器上的吞吐量作为一个糟糕的工作.它似乎并不想玩.我现在正在一个单独的位置执行我的日志记录,然后将其分流到SMTP服务器.我仍然不知道有谁真正困扰试图密切关注IIS SMTP服务器的行为,所以在撰写本文时这个问题没有答案.
那好吧...
好的,所以我现在已经在这个项目上工作了很长时间,我想我可能会与世界分享我的发现.
IIS SMTP服务器
使用IIS SMTP服务器创建的所有邮件都会在第一个实例中发送到分拣目录.如果您要发送一封邮件,那么您必须在Matrix时间运行才能真正看到它,因为它可能会立即发送.
在单个邮件出门的路上,它通过IIS中的队列文件夹.
如果您想观看性能计数器来监视此过程,您应该查看"远程队列长度".(原因是"本地队列长度"监视网络中"本地"发送的邮件.在这种情况下,"远程"指的是"外部进入世界"."本地"的具体定义在我们发送时逃脱了我没有本地邮件,但我想这意味着排队去服务器上的IIS的特定安装中包含的邮箱或其任何本地分组.)
从Exchange的角度来看,它似乎相当于在Exchange域中发送的邮件以及从该域发送到更广泛世界的邮件.
无论如何.远程队列长度并不能说明整个故事.您还必须查看远程重试队列,当前出站连接的数量,以及带和括号中队列目录中的实际文件数.
原因如下:
远程队列:所有尚未发送的消息,无论多少次尝试过.当前分配给任何打开的连接的邮件数量不计入,因为它们处于"正在尝试"状态.
远程重试队列:所有尚未发送的消息,在过去的某个时刻,已分配给打开的连接以进行传递.显然交付必定已经失败或者消息已经发送.当前分配给打开的连接以进行重试的任何消息都不会计算在内.
当前出站连接:显示服务器尝试发送排队邮件时,可以为出站连接分配多条消息.这样分配的消息不会计入远程队列或远程重试队列中.物理
队列目录中的文件:显示仍在Queue目录中的邮件数.这将随着邮件的成功交付而减少.
示例:如果队列目录中有0个出站连接和50个邮件,则远程队列,重试队列和物理文件都将在50处读取.当引发重试标志时(这是IIS中的设置),连接数增加并且队列中的邮件数量减少.在邮件发送之前,物理文件的数量保持不变.但是,由于可以在当前连接上发送多个邮件,因此1连接可能导致远程队列和重试队列长度为47或更低.如果在重试事件期间,任何邮件成功传递,则队列目录中的物理文件数将减少.当连接关闭时,队列计数器应该再次稳定.
记录
使用.Net的邮件库可以指定与IIS默认值分开的分拣目录.在这里,您可以对邮件进行排队并获得定制服务,以便偶尔将邮件移动到IIS服务将接管的IIS目录中并发送排队的邮件.
为此,您将查找SmtpClient对象的"DeliveryMethod"属性,该属性应设置为SmtpDeliveryMethod.SpecifiedPickupDirectory.
要实际设置SpecifiedPickupDirectory,您应该设置SmtpClient的PickupDirectoryLocation属性.
当邮件传递到此位置时,它们将存储为.eml文件.文件名是GUID.这意味着将以基本随机的顺序发送多封电子邮件.理论上,如果需要,您可以编写代码来解决这种情况..eml文件遵循标准格式,可以通过在记事本中打开.eml来读取.解析此将允许您提取日志的信息.
我希望IIS中SMTP服务器工作方式的这种高级概述对于与我在3月份所处位置相似的人有所帮助.
京公网安备 11010802040832号 | 京ICP备19059560号-6 