在查看IMAP module的PHP源代码时,您会发现imap_headerinfo函数正在使用mail_fetchstructure,这是来自c-client库的函数.
documentation for c-client解释了mail_fetchstructure函数的工作方式,如下所示:
This function causes a fetch of all the structured information
(envelope, internal date, RFC 822 size, flags, and body structure) for
the given msgno and, in the case of IMAP, up to MAPLOOKAHEAD (a
parameter in IMAP2.H) subsequent messages which are not yet in the
cache. No fetch is done if the envelope for the given msgno is already
in the cache. The ENVELOPE and the BODY for this msgno is returned.
It is possible for the BODY to be NIL, in which case no information is
available about the structure of the message body.
我找到的一个IMAP头文件将此前瞻值定义为20,因此对该函数的第一次调用使其从邮箱中获取20个附加消息.这解释了您观察到的每次调用该函数的时间比其他函数花费的时间要多得多的行为.
如果以相反的顺序获取消息,则会导致库首先加载21条消息,这些消息以您在函数调用中指定的消息开头.下一个调用检查所请求的消息是否已经被缓存,这不是因为它在之前加载的消息之前,因此缓存被丢弃并重复该过程.因此,反向循环中的每个调用最多将加载21条消息.
但是,这并不能真正解释不同邮箱大小的性能差异.
我对这种行为的解释比准确的研究更多猜测:c-client库还预先将消息号映射到它们适当的UID. IMAP头定义了UID前瞻计数1000.这可以解释一定程度的性能损失,但我不知道为什么这会导致如此大的差异,但这是我目前能够想出的唯一解释.
在具有1000和2000个消息的邮箱上尝试此操作可能会更好地了解此UID查找是否与其有关.如果是这样,500条消息和1000条消息之间的性能应该显着下降,而2000条消息应该与1000条消息一样慢.使用网络嗅探器检查服务器实际请求的数据也值得一试.不幸的是,我这里没有合适的测试环境来自己试试.