headers
Jason Munro | 1 May 2002 19:45

Marc's speed up patches

Hello all,
  As you may have noticed, Marc Groot Koerkamp's speed up changes from
  last week are in CVS. Together we worked out the bugs regarding UW and
  Courier without breaking compatibility with Cyrus.
I have tested with:

 Courier 1.4.2 from source on Redhat 7.1
 Courier 1.4.2 from source on Debian Unstable
 Cyrus 1.5.19 from apt-get on Debian Unstable
 UW 4:2001a-6 from apt-get on Debian Unstable

and have not found any problems yet :):)

Great Work Marc !!!

 \__ Jason Munro
  \__ AIM: jmunr0
   \__ jason <at> stdbev.com
Permalink | Reply | 4 comments |
headers
Robin Rainton | 1 May 2002 21:30
Favicon

Resource Usage?

Hi All,

Earlier this week I posted a message about this 'Killed' problem I occasionally see
in various parts of SM. I have discovered that my ISP has the following limits (set
with setrlimit):
Size of Core Files - 0 MB
CPU Time Used - 30 seconds
Data Size - 3 MB
File Size Created - 1 MB
Memory Locked - 1 MB
Number of Open Files - 32
Number of Simultaneous Processes - 8

Does this sound OK? SM should be able to run within these limits (well - it is doing
for me, only with a bit of trouble once in a while)? Of course, these limits are
per-process, so the PHP compiler, etc, has to fit in I assume.
What I don't get is that I see pages start to refresh (the left frame for example)
then get 'Killed' half way through. So most of the work is done, the program is
compiled, IMAP connection established, so they are trying to tell me that little
fetch a message, write the folder name loop is using loads of RAM? This can't be
right can it?
Any comments? Perhaps when we find what the limits are we can put them in the Wiki FAQ?

Robin

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net
--
(Continue reading)

Permalink | Reply | 5 comments |
headers
Paul Joseph Thompson | 1 May 2002 23:37
Favicon

Re: Marc's speed up patches

Jason Munro said:
> Hello all,
>  As you may have noticed, Marc Groot Koerkamp's speed up changes
>  from last week are in CVS. Together we worked out the bugs
>  regarding UW and Courier without breaking compatibility with
>  Cyrus.
> I have tested with:
>
> Courier 1.4.2 from source on Redhat 7.1
> Courier 1.4.2 from source on Debian Unstable
> Cyrus 1.5.19 from apt-get on Debian Unstable
> UW 4:2001a-6 from apt-get on Debian Unstable
>
> and have not found any problems yet :):)
>
> Great Work Marc !!!

I have tried this with the compile of Cyrus 1.5.19 in Debian STABLE,
and it works as well...
I'd like to complain that the folder list can be horrically slow to
load, considering the relatively SMALL amount of data that is being
retrieved to display it. Anyone want to take on the challenge to
optimize that, next?
Marc, anyone? :)

--

-- 
Paul Joseph Thompson
captbunzo <at> squirrelmail.org
AIM/Yahoo/MSN IM: Captain Bunzo
ICQ Number: 38801719
(Continue reading)

Permalink | Reply | 3 comments |
headers
Robin Rainton | 2 May 2002 00:21
Favicon

Re: Resource Usage?

Arghhhh!!!! I'm going crazy here, can one of you PHP guru's help me out here?

I put loads of logging to report the idrss usage and get something like:

Getting sizes for INBOX
ru_idrss 124840

-- asking for A036 FETCH 1:25 BODY.PEEK[HEADER.FIELDS (Date To From Cc Subject
Message-Id X-Priority Content-Type In-Reply-To)]--ru_idrss 129512

-- asking for A036 FETCH 1:25 RFC822.SIZE
-- ru_idrss 138924

-- Processing results
-- ru_idrss 138924

-- returning results
-- ru_idrss 249116

Got sizes for INBOX
ru_idrss 249116

Returning sizes for INBOX
ru_idrss 249116

I've indented the logging I put in sqimap_get_small_header_list with '--' and the
other stuff comes from my get_folder_size function.
Look at that massive jump in usage during sqimap_get_small_header_list. This is new
memory allocated between lines 414 and 497 (ish - I may have moved them a little) in
imap_messages.php. I see a lot of new 'small_header' objects being created but surly
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jason Munro | 2 May 2002 00:52

Re: Resource Usage?

Robin Rainton said:
> Arghhhh!!!! I'm going crazy here, can one of you PHP guru's help me out
> here?
>
> I put loads of logging to report the idrss usage and get something
> like:
>
> Getting sizes for INBOX
> ru_idrss 124840
>
> -- asking for A036 FETCH 1:25 BODY.PEEK[HEADER.FIELDS (Date To From Cc
> Subject Message-Id X-Priority Content-Type In-Reply-To)]--ru_idrss
> 129512
>
> -- asking for A036 FETCH 1:25 RFC822.SIZE
> -- ru_idrss 138924
>
> -- Processing results
> -- ru_idrss 138924
>
> -- returning results
> -- ru_idrss 249116
>
> Got sizes for INBOX
> ru_idrss 249116
>
> Returning sizes for INBOX
> ru_idrss 249116
>
> I've indented the logging I put in sqimap_get_small_header_list with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robin Rainton | 2 May 2002 10:02
Favicon

Re: Resource Usage?

Jason,

I took the cvs version of functions/imap*.php and put them ontop of my 1.2.6 release.

Yep - I notice this is faster, and the memory usage lower. Message sizes to scan my
26 folders/500 messages consumes around 500K now when it works which is a big drop
(was over 2Mb before, even when it worked).
The 'Killed' message is seen less frequently (at first appearance) but it still
occurs. I still see a refresh of the left frame folder list being killed
occasionally too though.
I think this is a step in the right direction, but I must assume that for some
reason PHP is going AWOL once in a while and trying to allocate massises of memory
for no particular reason. I can only assume this is happening in the
sqimap_get_small_header_list function, probably in what I would call the main
processing section (two nested loops starting line 395 in current CVS). This doesn't
look overly complex code though - I will bang more logging in there and see what I
can find.
Keep you posted,

Robin

Jason Munro said:
> Robin Rainton said:

[ snip my own ramblings ;-) ]

> It just so happens that some changes were made to the get small header function
> in CVS (made earlier today) that really speed up the process. Perhaps you should
> try it and see what happens. The calls for
> flags/internal date/rfc.size were integrated into the body.peek imap call,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Groot Koerkamp | 2 May 2002 10:14
Picon

Re: Marc's speed up patches

Hello Paul,

About the mailboxes thing, I don't have time now but I did have a look and
I think (I'm not sure) that the LIST command is used to much.
The way things go now:
Something with LSUB (I don't get the meaning of that very well)
For each mailbox in LSUB we do a LIST and I think we should do something with
LIST "" "$mbx.*" and get all the mailboxes at once instead of LIST them
individual.
Maybe someone can look at the imap logs and confirm if the LIST command is
used to much. Or can somebody tell me how I put on the imap-log on a cyrus
2.0.16 server. All my efforts didn't work until now :-(.
Who wrote that code by the way? He should understand what is going on.

Regards,

Marc Groot Koerkamp

Paul Joseph Thompson zei:
> Jason Munro said:
>> Hello all,
>>  As you may have noticed, Marc Groot Koerkamp's speed up changes from
>>  last week are in CVS. Together we worked out the bugs
>>  regarding UW and Courier without breaking compatibility with
>>  Cyrus.
>> I have tested with:
>>
>> Courier 1.4.2 from source on Redhat 7.1
>> Courier 1.4.2 from source on Debian Unstable
>> Cyrus 1.5.19 from apt-get on Debian Unstable
(Continue reading)

Permalink | Reply | 1 comment |
headers
Axel Wagner | 2 May 2002 12:24
Picon

Problems with Special Characters in Attachments (e.g. german umlauts)

On Tue, Apr 30, 2002 at 03:11:01PM +0200, Ralf Hildebrandt wrote:
> Am 30.04.2002 um 15:02:02 +0200 schrieb Axel Wagner folgendes:
> > Hi Everybody,
> >
> >   we have encountered some weird behavior with SM 1.2.5 and
> >   Attachments that contains german special characters.
>
> Schonmal das Update auf den aktuellen Release 1.2.6 versucht?

Update to 1.2.6 performed: same result!
At least the file suffix seems to survive the name mangling
(e.g. "Ätsch.txt" will be downloaded as "untitled.txt".

Does anyone precisly know if plain special characters are allowed
in MIME header. I often see sort of ISO-8859-1 or 8859-15 encodings
(containing something like '=?ISO-8859-1?....?=' as filename/name
for MIME attachments. Seems to me that there is no common
agreement on how to encode non-US ASCII characters?

Bye

Axel Wagner

--

-- 
 #####   ######   ###### | Axel Wagner -  GBF Rechenzentrum
##       ##   ##  ##	 | Mascheroder Weg 1B -  38124 Braunschweig
## ####  ######   ####   | Tel: 0531/6181-352
##   ##  ##   ##  ##	 | Fax: 0531/6181-355
 #####   ######   ##	 | http://www.gbf.de - <axel.wagner <at> gbf.de>
(Continue reading)

Permalink | Reply | 752 comments |
headers
Marc Groot Koerkamp | 2 May 2002 15:54
Picon

Implementatation of add adres to addresbook in read_body

Hello,

Today I implemented a link in read_body.php to open the addres_book (with
javascript or the normal way).The from address is automaticly parsed to the inputfields in addresbook.
I do a guess which is the firstname and lastname.
Suppose the $from_name = "Marc Groot Koerkamp" <marc <at> its-projects.nl> then
the firstname is found by spitting up the name after the first space.
If the name is "Groot Koerkamp, Marc" <marc <at> its-projects.nl> then the
firstname is found by looking for the ',' .
I have however one problem. I want to set the nickname to "Marc groot
Koerkamp" but addressbook.php complains about illegal characters in my
nick.
I appears that spaces aren't allowed in the nick. Is there a reason for that?
If I comment out the check for illegal characters everything works fine.

Do you want this implementation in SM 1.2.7?

Regards,

Marc Groot Koerkamp.

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net
--
squirrelmail-devel mailing list
List Address: squirrelmail-devel <at> lists.sourceforge.net
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
http://squirrelmail.org/cvs
(Continue reading)

Permalink | Reply | 6 comments |
headers
Robin Rainton | 2 May 2002 16:50
Favicon

Re: Implementatation of add adres to addresbook in read_body

To add my 2c...

I'd like to see a change where you are not forced to enter a nickname. Sometimes
it's useful (for people you mail a lot) but other times it's very annoying (I just
end up putting 'first_last' all the time).
Is there any reason it can't be changed so nicknames aren't enforced?

Marc Groot Koerkamp said:
> Hello,
>
> Today I implemented a link in read_body.php to open the addres_book (with
> javascript or the normal way).The from address is automaticly parsed to the
> inputfields in addresbook. I do a guess which is the firstname and lastname.
> Suppose the $from_name = "Marc Groot Koerkamp" <marc <at> its-projects.nl> then the
> firstname is found by spitting up the name after the first space. If the name is
> "Groot Koerkamp, Marc" <marc <at> its-projects.nl> then the firstname is found by
> looking for the ',' .
> I have however one problem. I want to set the nickname to "Marc groot Koerkamp"
> but addressbook.php complains about illegal characters in my nick.
> I appears that spaces aren't allowed in the nick. Is there a reason for that? If
> I comment out the check for illegal characters everything works fine.
>
> Do you want this implementation in SM 1.2.7?
>
> Regards,
>
> Marc Groot Koerkamp.
>
>
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane