From: eCet <ec...@sl...> - 2006-03-20 15:10:38
|
Tomas Kuliavas wrote: > > In order to calculate threads imap server must parse all messages and > store thread data until parsing is finished. It takes lots of time and > memory. Enable info plugin in sm 1.5.1 and compare timings of SORT and > THREAD tests. Yes, THREAD is mutch more slower than SORT. > > I suspect that courier hits process memory limits or php connection > timeouts. I'we checked. The memory limit is the default 64MBytes, it is plenty enough for mutch bigger mailboxes. >If issue is caused by PHP stream data exchange timeout, we > should find default php stream timeout value and try increasing timeout > values in php 4.3+ or at least detect dropped connection. I'we increased default socket timeout in php.ini from 60secs to 880secs, and it is not working. No errors, only blank screen. I have: error_reporting = E_ALL display_errors = Off log_errors = On No errors in log. >If connection is dropped by courier - you should be able to reproduce it by issuing > threading request in plain telnet connection to imap port. > OK. I'we tried with telnet. It is working good. (took 5.5 minutes ) ... ... a01 OK LOGIN Ok. a01 select INBOX * FLAGS (NonJunk \Draft \Answered \Flagged \Deleted \Seen \Recent) ... ... a01 OK [READ-WRITE] Ok ... ... 2941 22945)(22951))(22942 22955 22956)(22948)(22949)(22960) a02 OK THREAD done. So the problem is around php/SM. It is OK to increase memory limits, timigs, but it will not work in extreme environments like 600.000 mails or 1Mill mail, and the way it is slow now with 22.000mail it is unusable. At 100.000 mails one mailbox operation will take from 10minutes till 1hour. How can that big mailbox handled in SM? I'm not familiar with imap, but can that be not to query, and sort all messages at once? Only smaller peaces of it (eg5000 messages per slice). Than if user wants to view older mails then read another 5000 mails in the interval the user vants? |