[Dbmail] Dropping characters.
I know this isn't directly related to dbmail, but the people on the php-db mailing list aren't being too helpful and I was wondering if anyone here had any ideas. I've been having an issue where php will drop the first four characters from a POSTed form field when inserting/updating information in MySQL. I noticed while trying to add users to the DBMail database, and I can't figure out what's going on. At first I thought it might be my script, but if I do things manually with a tool like PHPMyadmin it drops the characters too. I started noticing the problem last week after I upgraded to php 4.2.3. It's always four characters, and it never happens when I have less than four fields in a form. I'm running RH 7.2, MySQL 3.23, and PHP 4.2.3. Any help, or ideas of where to look for problems would be appreciated. Thank you, -Micah
RE: [Dbmail] Dropping characters.
Michael Rose, Jr. Office: (206) 686-7600 Fax: (206) 374-8126 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Micah Stevens Sent: Monday, September 23, 2002 3:00 PM To: dbmail@dbmail.org Subject: [Dbmail] Dropping characters. I know this isn't directly related to dbmail, but the people on the php-db mailing list aren't being too helpful and I was wondering if anyone here had any ideas. I've been having an issue where php will drop the first four characters from a POSTed form field when inserting/updating information in MySQL. I noticed while trying to add users to the DBMail database, and I can't figure out what's going on. At first I thought it might be my script, but if I do things manually with a tool like PHPMyadmin it drops the characters too. I started noticing the problem last week after I upgraded to php 4.2.3. It's always four characters, and it never happens when I have less than four fields in a form. I'm running RH 7.2, MySQL 3.23, and PHP 4.2.3. Any help, or ideas of where to look for problems would be appreciated. Thank you, -Micah ___ Dbmail mailing list Dbmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
RE: [Dbmail] Dropping characters.
Use phpinfo(); to figure out if the missing four characters are being lost in PHP or when you're doing the INSERT or UPDATE into mysql. Also try doing the INSERT/UPDATE via the mysql command line. Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Micah Stevens Sent: Monday, September 23, 2002 3:00 PM To: dbmail@dbmail.org Subject: [Dbmail] Dropping characters. I know this isn't directly related to dbmail, but the people on the php-db mailing list aren't being too helpful and I was wondering if anyone here had any ideas. I've been having an issue where php will drop the first four characters from a POSTed form field when inserting/updating information in MySQL. I noticed while trying to add users to the DBMail database, and I can't figure out what's going on. At first I thought it might be my script, but if I do things manually with a tool like PHPMyadmin it drops the characters too. I started noticing the problem last week after I upgraded to php 4.2.3. It's always four characters, and it never happens when I have less than four fields in a form. I'm running RH 7.2, MySQL 3.23, and PHP 4.2.3. Any help, or ideas of where to look for problems would be appreciated. Thank you, -Micah ___ Dbmail mailing list Dbmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
RE: [Dbmail] Dropping characters.
It's definitely something with the php interface. If I do anything at the command line, with MySQL, it works fine. I attached the phpinfo() output. I'm not sure how I'm supposed to directly use that to figure out if the characters are being lost by PHP. I did notice however, that after an attempted query with phpmyadmin, the script will display the SQL used, which is lacking the characters as well. So it seems that the script isn't getting the proper data. I tried things out in IE 5.5, Opera 5, and Netscape 6, and they all do it, so it's not the browser dropping stuff. -Micah At 03:20 PM 9/23/2002 -0700, you wrote: Use phpinfo(); to figure out if the missing four characters are being lost in PHP or when you're doing the INSERT or UPDATE into mysql. Also try doing the INSERT/UPDATE via the mysql command line. Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Micah Stevens Sent: Monday, September 23, 2002 3:00 PM To: dbmail@dbmail.org Subject: [Dbmail] Dropping characters. I know this isn't directly related to dbmail, but the people on the php-db mailing list aren't being too helpful and I was wondering if anyone here had any ideas. I've been having an issue where php will drop the first four characters from a POSTed form field when inserting/updating information in MySQL. I noticed while trying to add users to the DBMail database, and I can't figure out what's going on. At first I thought it might be my script, but if I do things manually with a tool like PHPMyadmin it drops the characters too. I started noticing the problem last week after I upgraded to php 4.2.3. It's always four characters, and it never happens when I have less than four fields in a form. I'm running RH 7.2, MySQL 3.23, and PHP 4.2.3. Any help, or ideas of where to look for problems would be appreciated. Thank you, -Micah ___ Dbmail mailing list Dbmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail ___ Dbmail mailing list Dbmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
RE: [Dbmail] Dropping characters.
Here's the attachment. At 03:20 PM 9/23/2002 -0700, you wrote: Use phpinfo(); to figure out if the missing four characters are being lost in PHP or when you're doing the INSERT or UPDATE into mysql. Also try doing the INSERT/UPDATE via the mysql command line. Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Micah Stevens Sent: Monday, September 23, 2002 3:00 PM To: dbmail@dbmail.org Subject: [Dbmail] Dropping characters. I know this isn't directly related to dbmail, but the people on the php-db mailing list aren't being too helpful and I was wondering if anyone here had any ideas. I've been having an issue where php will drop the first four characters from a POSTed form field when inserting/updating information in MySQL. I noticed while trying to add users to the DBMail database, and I can't figure out what's going on. At first I thought it might be my script, but if I do things manually with a tool like PHPMyadmin it drops the characters too. I started noticing the problem last week after I upgraded to php 4.2.3. It's always four characters, and it never happens when I have less than four fields in a form. I'm running RH 7.2, MySQL 3.23, and PHP 4.2.3. Any help, or ideas of where to look for problems would be appreciated. Thank you, -Micah ___ Dbmail mailing list Dbmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail ___ Dbmail mailing list Dbmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail Title: phpinfo() PHP Version 4.2.3 System Linux raincross-tech.com 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001 i686 unknown Build Date Sep 16 2002 13:35:33 Configure Command './configure' '--with-apxs' '--with-openssl' '--with-zlib' '--enable-bcmath' '--enable-calendar' '--with-jpeg-dir' '--with-tiff-dir' '--enable-ctype' '--with-gdbm' '--with-ndbm' '--with-dom' '--enable-exif' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local/lib' '--with-ttf' '--with-ming=/root/ming-0.1.1' '--with-mysql' '--with-pdflib' '--with-pgsql=shared' '--enable-trans-sid' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-versioning' '--enable-inline-optimization' '--enable-memory-limit' '--enable-mbstring' '--enable-wddx' '--enable-mbstr-enc-trans' '--enable-magic-quotes' Server API Apache Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib/php.ini Debug Build no Thread Safety disabled This program makes use of the Zend Scripting Language Engine:Zend Engine v1.2.0, Copyright (c) 1998-2002 Zend Technologies PHP 4 Credits Configuration PHP Core Directive Local Value Master Value allow_call_time_pass_reference On On allow_url_fopen 1 1 always_populate_raw_post_data 1 1 arg_separator.input & & arg_separator.output & & asp_tags Off Off auto_append_file no value no value auto_prepend_file no value no value browscap no value no value default_charset no value no value default_mimetype text/html text/html define_syslog_variables Off Off disable_functions no value no value display_errors Off Off display_startup_errors On On doc_root no value no value enable_dl On On error_append_string error_log syslog syslog error_prepend_string error_reporting 2047 2047 expose_php On On extension_dir /usr/lib/php4/ /usr/lib/php4/ file_uploads 1 1 gpc_order GPC GPC highlight.bg #FF #FF highlight.comment #FF9900 #FF9900 highlight.default #CC #CC highlight.html #00 #00 highlight.keyword #006600 #006600 highlight.string #CC #CC html_errors On On ignore_user_abort Off Off implicit_flush Off Off include_path .:/usr/share/php/includes:/usr/share/php/PEAR/ .:/usr/share/php/includes:/usr/share/php/PEAR/ log_errors On On magic_quotes_gpc Off Off magic_quotes_runtime Off Off magic_quotes_sybase Off Off max_execution_time 60 60 memory_limit 8M 8M open_basedir no value no value output_buffering no value no value output_handler no value no value post_max_size 8M 8M precision 12
RE: [Dbmail] Imapd is slow as hell
Hi, We have noticed that and make some tests with several Webmail and mail clients as Netscape, Outlook, vs courier-imap with the same mail clients. First conclusions the PHPs' webmails are very slow except Squirrelmail because it use its own imap libraries instead of PHP-IMAP. But it's true Courier-IMAP it's much faster than dbmail-imap, we have add the mysql indexes as explained in this list, tuned the mysql config and got some improvements but never too fast as courier-imap. Then we have put the trace_level to 5 and make the same tests and we have noticed that to get each mail header dbmail-imap need 4 or 5 queries and in my opinion I think that it should be possible to get the same think with only one or two: By use a "SELECT * FROM messages" instead "SELECT field-1, field-2..." and/or change the table structure to put the mail header on "messages" whith the from:, to:, subject:, field and perhaps the body too, or just the body on messageblks. DBmail is the right way to make an isp mail solution with a lot of capabilities as CRM, etc, but we have to improve its speed and discuss to find the best way to do. Shih Ming-Wei a dit : > My imap is working fine but pop3 is very slow, I have ask a few times > on the list but apparently nobody is interested :( > > Ming-Wei > > -Original Message- > From: John Wall [mailto:[EMAIL PROTECTED] > Sent: Monday, August 26, 2002 9:24 AM > To: dbmail@dbmail.org > Subject: [Dbmail] Imapd is slow as hell > > > Imapd is slow as hell. > > pop3d is fast when i press "send and recive" but on my imapd account > it takes up to a minute before it tryes to login. I heave allready > check DNS and my host file. > > Imapd works fast sometimes and sometimes it slow as hell. I got only 3 > users on that mailserver with dbmail. The server it runs on is strong > so there is no problem with the server. > > The slow part is when I login to the imapd server, it takes up to a > minute before I see any login tries in the logfile. This is so wierd > ... > > /John -- Sam Przyswa - Chef de projet Arial Concept - Intégrateur Internet 36, rue de Turin - 75008 - Paris Tel: 01 40 54 86 04 - Fax: 01 40 54 83 01 Web: http://www.arial-concept.com - Email: [EMAIL PROTECTED]
RE: [Dbmail] Imapd is slow as hell
Just a note, on your query comments, although I'm not arguing with your basic point, it's always been my understanding that SELECT statements that use '*' instead of stating field names are slower. If you don't specify the field names the database has to spend time figuring out what they are, but if you name them all it has to do it error if it can't find the name. In practice I've noticed it to be only marginally faster to explicitly name the fields rather than use the '*' wildcard. Not really noticeable unless you're doing tons of SELECT statements. Back to the point of your mail though: Is it faster to make one big conglomerate SQL statement that takes the database longer to parse? If it's the difference between one connection, and two, I doubt it, but the more you slim things down the better. That's for sure. I hate Mondays. -Micah At 03:26 AM 9/24/2002 +0200, you wrote: Hi, We have noticed that and make some tests with several Webmail and mail clients as Netscape, Outlook, vs courier-imap with the same mail clients. First conclusions the PHPs' webmails are very slow except Squirrelmail because it use its own imap libraries instead of PHP-IMAP. But it's true Courier-IMAP it's much faster than dbmail-imap, we have add the mysql indexes as explained in this list, tuned the mysql config and got some improvements but never too fast as courier-imap. Then we have put the trace_level to 5 and make the same tests and we have noticed that to get each mail header dbmail-imap need 4 or 5 queries and in my opinion I think that it should be possible to get the same think with only one or two: By use a "SELECT * FROM messages" instead "SELECT field-1, field-2..." and/or change the table structure to put the mail header on "messages" whith the from:, to:, subject:, field and perhaps the body too, or just the body on messageblks. DBmail is the right way to make an isp mail solution with a lot of capabilities as CRM, etc, but we have to improve its speed and discuss to find the best way to do. Shih Ming-Wei a dit : > My imap is working fine but pop3 is very slow, I have ask a few times > on the list but apparently nobody is interested :( > > Ming-Wei > > -Original Message- > From: John Wall [mailto:[EMAIL PROTECTED] > Sent: Monday, August 26, 2002 9:24 AM > To: dbmail@dbmail.org > Subject: [Dbmail] Imapd is slow as hell > > > Imapd is slow as hell. > > pop3d is fast when i press "send and recive" but on my imapd account > it takes up to a minute before it tryes to login. I heave allready > check DNS and my host file. > > Imapd works fast sometimes and sometimes it slow as hell. I got only 3 > users on that mailserver with dbmail. The server it runs on is strong > so there is no problem with the server. > > The slow part is when I login to the imapd server, it takes up to a > minute before I see any login tries in the logfile. This is so wierd > ... > > /John -- Sam Przyswa - Chef de projet Arial Concept - Intégrateur Internet 36, rue de Turin - 75008 - Paris Tel: 01 40 54 86 04 - Fax: 01 40 54 83 01 Web: http://www.arial-concept.com - Email: [EMAIL PROTECTED] ___ Dbmail mailing list Dbmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
[Dbmail] Amavisd-new
I am trying to find the mailing list for amavisd-new-20020630. Anyone know where I can find a list or contact for assistance getting this program running? -- Butch Evans 573-293-2638 BPS Networks PO BOX 550 114 W Main Bernie, MO 63822
RE: [Dbmail] Amavisd-new
Wouldn't it be part of the existing mailing list? http://lists.sourceforge.net/lists/listinfo/amavis-user Michael Rose, Jr. Office: (206) 686-7600 Fax: (206) 374-8126 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Butch Evans Sent: Monday, September 23, 2002 9:12 PM To: dbmail@dbmail.org Subject: [Dbmail] Amavisd-new I am trying to find the mailing list for amavisd-new-20020630. Anyone know where I can find a list or contact for assistance getting this program running? -- Butch Evans 573-293-2638 BPS Networks PO BOX 550 114 W Main Bernie, MO 63822 ___ Dbmail mailing list Dbmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] Imapd is slow as hell
On Mon, 23 Sep 2002 18:48:33 -0700 in message <[EMAIL PROTECTED]>, Micah Stevens <[EMAIL PROTECTED]> wrote: > Just a note, on your query comments, although I'm not arguing with your > basic point, it's always been my understanding that SELECT statements that > use '*' instead of stating field names are slower. If you don't specify the > field names the database has to spend time figuring out what they are, but > if you name them all it has to do it error if it can't find the name. Probably depends on the implementation. But if you're looking for a speed up there, you're probably barking up the wrong tree. You're better off trying to optimize away a call to the database. Any decent database will already have the column descriptions cached anyway. But even worse, select * can be a maintence nightmare. Unless your program is getting back the rows as name value pairs and picking through what gets sent back, you want to be specifying the columns and the order that they are to be sent back, not asking for everything and assuming that the order and number of the fields is what you think might be there. (because someone like me be implementing that table as a view, or adding columns for my use, or something like that. ) eric
Re: [Dbmail] Amavisd-new
On Monday 23 September 2002 11:28 pm, Michael Rose, Jr. wrote: > Wouldn't it be part of the existing mailing list? > > http://lists.sourceforge.net/lists/listinfo/amavis-user This is correct. Bret. -- Bret Baptist Systems and Technical Support Specialist [EMAIL PROTECTED] Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 x17 Web Development-Web Marketing-ISP Services -- Today is the tomorrow you worried about yesterday.
RE: [Dbmail] Imapd is slow as hell
Micah Stevens ([EMAIL PROTECTED]) wrote: > >Just a note, on your query comments, although I'm not arguing with your >basic point, it's always been my understanding that SELECT statements that >use '*' instead of stating field names are slower. If you don't specify the >field names the database has to spend time figuring out what they are, but >if you name them all it has to do it error if it can't find the name. > >In practice I've noticed it to be only marginally faster to explicitly name >the fields rather than use the '*' wildcard. Not really noticeable unless >you're doing tons of SELECT statements. Either or not use wildcards it should be faster to get the header in one query instead of five, I think. >Back to the point of your mail though: Is it faster to make one big >conglomerate SQL statement that takes the database longer to parse? If it's >the difference between one connection, and two, I doubt it, but the more >you slim things down the better. That's for sure. If the message is stored directly in "messages" instead of "messages" + "messageblks" the query look like: "SELECT * FROM messages WHERE message_idnr = AND status<2 AND unique_id ! = '' AND mailbox_idnr = " ...or for exemple: "SELECT from,to,subject,seen_flag FROM messages WHERE message_idnr = AND status<2 AND unique_id != '' AND mailbox_idnr = " My second question: why to use the extra table messageblks to store the message ? Thanks for spend your time to reply to my questions. Sam. >At 03:26 AM 9/24/2002 +0200, you wrote: >>Hi, >> >>We have noticed that and make some tests with several Webmail and mail >>clients as Netscape, Outlook, vs courier-imap with the same mail >>clients. >> >>First conclusions the PHPs' webmails are very slow except Squirrelmail >>because it use its own imap libraries instead of PHP-IMAP. But it's true >>Courier-IMAP it's much faster than dbmail-imap, we have add the mysql >>indexes as explained in this list, tuned the mysql config and got some >>improvements but never too fast as courier-imap. >> >>Then we have put the trace_level to 5 and make the same tests and we >>have noticed that to get each mail header dbmail-imap need 4 or 5 >>queries and in my opinion I think that it should be possible to get the >>same think with only one or two: >> >>By use a "SELECT * FROM messages" instead "SELECT field-1, field-2..." >>and/or change the table structure to put the mail header on "messages" >>whith the from:, to:, subject:, field and perhaps the body too, or just >>the body on messageblks. >> >>DBmail is the right way to make an isp mail solution with a lot of >>capabilities as CRM, etc, but we have to improve its speed and discuss >>to find the best way to do. >> -- Sam Przyswa - Chef de projet Arial Concept - Intégrateur Internet 36, rue de Turin - 75008 - Paris Tel: 01 40 54 86 04 - Fax: 01 40 54 83 01 Web: http://www.arial-concept.com - Email: [EMAIL PROTECTED]
Re: [Dbmail] Imapd is slow as hell
Why use messageblks? Well, for one reason, mysql has a limit on the record size so a split-up is necessary anyway. The system was chosen to handle big messages in chunks. - Original Message - From: "Sam Przyswa" <[EMAIL PROTECTED]> To: Sent: Tuesday, September 24, 2002 3:52 PM Subject: RE: [Dbmail] Imapd is slow as hell > Micah Stevens ([EMAIL PROTECTED]) wrote: > > > >Just a note, on your query comments, although I'm not arguing with your > >basic point, it's always been my understanding that SELECT statements that > >use '*' instead of stating field names are slower. If you don't specify the > >field names the database has to spend time figuring out what they are, but > >if you name them all it has to do it error if it can't find the name. > > > >In practice I've noticed it to be only marginally faster to explicitly name > >the fields rather than use the '*' wildcard. Not really noticeable unless > >you're doing tons of SELECT statements. > > Either or not use wildcards it should be faster to get the header in one query > instead of five, I think. > > >Back to the point of your mail though: Is it faster to make one big > >conglomerate SQL statement that takes the database longer to parse? If it's > >the difference between one connection, and two, I doubt it, but the more > >you slim things down the better. That's for sure. > > If the message is stored directly in "messages" instead of "messages" > + "messageblks" the query look like: > > "SELECT * FROM messages WHERE message_idnr = AND status<2 AND unique_id ! > = '' AND mailbox_idnr = " > > ...or for exemple: > > "SELECT from,to,subject,seen_flag FROM messages WHERE message_idnr = AND > status<2 AND unique_id != '' AND mailbox_idnr = " > > My second question: why to use the extra table messageblks to store the message ? > > Thanks for spend your time to reply to my questions. > > Sam. > > >At 03:26 AM 9/24/2002 +0200, you wrote: > >>Hi, > >> > >>We have noticed that and make some tests with several Webmail and mail > >>clients as Netscape, Outlook, vs courier-imap with the same mail > >>clients. > >> > >>First conclusions the PHPs' webmails are very slow except Squirrelmail > >>because it use its own imap libraries instead of PHP-IMAP. But it's true > >>Courier-IMAP it's much faster than dbmail-imap, we have add the mysql > >>indexes as explained in this list, tuned the mysql config and got some > >>improvements but never too fast as courier-imap. > >> > >>Then we have put the trace_level to 5 and make the same tests and we > >>have noticed that to get each mail header dbmail-imap need 4 or 5 > >>queries and in my opinion I think that it should be possible to get the > >>same think with only one or two: > >> > >>By use a "SELECT * FROM messages" instead "SELECT field-1, field-2..." > >>and/or change the table structure to put the mail header on "messages" > >>whith the from:, to:, subject:, field and perhaps the body too, or just > >>the body on messageblks. > >> > >>DBmail is the right way to make an isp mail solution with a lot of > >>capabilities as CRM, etc, but we have to improve its speed and discuss > >>to find the best way to do. > >> > -- > Sam Przyswa - Chef de projet > Arial Concept - Intégrateur Internet > 36, rue de Turin - 75008 - Paris > Tel: 01 40 54 86 04 - Fax: 01 40 54 83 01 > Web: http://www.arial-concept.com - Email: [EMAIL PROTECTED] > > > ___ > Dbmail mailing list > Dbmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail >
Re: [Dbmail] Imapd is slow as hell
eric ([EMAIL PROTECTED]) écrivait: > >On Mon, 23 Sep 2002 18:48:33 -0700 in message <[EMAIL PROTECTED]>, Micah Stevens <[EMAIL PROTECTED]> wrote: >> Just a note, on your query comments, although I'm not arguing with your >> basic point, it's always been my understanding that SELECT statements that >> use '*' instead of stating field names are slower. If you don't specify the >> field names the database has to spend time figuring out what they are, but >> if you name them all it has to do it error if it can't find the name. > >Probably depends on the implementation. But if you're looking for a speed up there, you're probably barking up the wrong tree. You're better off trying to optimize away a call to the database. Any decent database will already have the column descriptions cached anyway. But even worse, select * can be a maintence nightmare. > >Unless your program is getting back the rows as name value pairs and picking through what gets sent back, you want to be specifying the columns and the order that they are to be sent back, not asking for everything and assuming that the order and number of the fields is what you think might be there. Sure it's easiest to SELECT named fields as SELECT * and use raw[x] to get the value. Our main goal it's to speed up DBmail and any suggestions are welcome ! Sam. -- Sam Przyswa - Chef de projet Arial Concept - Intégrateur Internet 36, rue de Turin - 75008 - Paris Tel: 01 40 54 86 04 - Fax: 01 40 54 83 01 Web: http://www.arial-concept.com - Email: [EMAIL PROTECTED]
Re: [Dbmail] Imapd is slow as hell
Roel Rozendaal ([EMAIL PROTECTED]) écrivait: > >Why use messageblks? Well, for one reason, mysql has a limit on the record >size so a split-up is necessary anyway. The system was chosen to handle big >messages in chunks. > Ok, I guessed that there is a good reason to do that, but it's possible to use messageblks only to store the body part of the mail, then we don't need to accede to it to fetch the headers fields by putting them into the messages table, what did you think about ? Sam. -- Sam Przyswa - Chef de projet Arial Concept - Intégrateur Internet 36, rue de Turin - 75008 - Paris Tel: 01 40 54 86 04 - Fax: 01 40 54 83 01 Web: http://www.arial-concept.com - Email: [EMAIL PROTECTED]
Re: [Dbmail] Imapd is slow as hell
The basic layout for dbmail was based upon pop3 but we are interested in better schemes for imap. One of the main goals right now is to have the fastest imap server around. Better table layouts would mean a great improvement; just don't know how much time will be involved in implementing those. Things to do right now in my opinion are to fix annoying bugs and update the package with the several patches we have to release a STABLE 1.0 version asap. Right after that we can start playing with the table layouts and imap server logic to maximize speed for a 2.0 imap update. On Tue, 2002-09-24 at 18:03, Sam Przyswa wrote: > Roel Rozendaal ([EMAIL PROTECTED]) écrivait: > > > >Why use messageblks? Well, for one reason, mysql has a limit on the record > >size so a split-up is necessary anyway. The system was chosen to handle big > >messages in chunks. > > > > Ok, I guessed that there is a good reason to do that, but it's possible to use > messageblks only to store the body part of the mail, then we don't need to > accede > to it to fetch the headers fields by putting them into the messages table, > what > did you think about ? > > Sam. > -- > Sam Przyswa - Chef de projet > Arial Concept - Intégrateur Internet > 36, rue de Turin - 75008 - Paris > Tel: 01 40 54 86 04 - Fax: 01 40 54 83 01 > Web: http://www.arial-concept.com - Email: [EMAIL PROTECTED] > > > ___ > Dbmail mailing list > Dbmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail signature.asc Description: This is a digitally signed message part
Re: [Dbmail] Imapd is slow as hell
Roel Rozendaal ([EMAIL PROTECTED]) écrivait: > >The basic layout for dbmail was based upon pop3 but we are interested in >better schemes for imap. One of the main goals right now is to have the >fastest imap server around. Better table layouts would mean a great >improvement; just don't know how much time will be involved in >implementing those. Yes I know ! >Things to do right now in my opinion are to fix annoying bugs and update >the package with the several patches we have to release a STABLE 1.0 >version asap. Sure, we have already talked about that one week ago, in the bug fix list can you add the "&" character un the mailbox name to permit the UTF code, and permit dbmail to accept ISO-8859-1 charset for search functions, at this time we got an error message with Squirrelmail "unsupported character set". >Right after that we can start playing with the table layouts and imap >server logic to maximize speed for a 2.0 imap update. I will try to work on the imap speed improvements and will tell you if we got good results. Thanks for your work and your attention. Sam.
Re: [Dbmail] Imapd is slow as hell
On Tue, 2002-09-24 at 10:48, Sam Przyswa wrote: > >Unless your program is getting back the rows as name value pairs and picking > through what gets sent back, you want to be specifying the columns and the > order > that they are to be sent back, not asking for everything and assuming that the > order and number of the fields is what you think might be there. > > Sure it's easiest to SELECT named fields as SELECT * and use raw[x] to get the > value. Our main goal it's to speed up DBmail and any suggestions are welcome ! > That is not the easiest method, because unless you're getting it as an associative array (name/val pairs, etc) Then you have no idea if raw[4] is really what you expect on every installation (someone may have added a field they need to the table). That is why the inserts and selects only ask for the columns they need in the order they need. So that the underlying table can be changed and not botch the whole system.
[Dbmail] dbmail and some possibilities?
Hello, community! I tried using dbmail (it`s the single thing in area loging emails), but I had some questions. 1. It`s very intresting for me to install dbmail on sendmail daemon. 2. It`s posible to put into DB not only input emails (for local users), but output email? 3. And it`s posible to organaze virtual boxes on every ip`s? Beforehand Grateful for answer. --- Dimitry // [EMAIL PROTECTED]
Re: [Dbmail] Imapd is slow as hell
Honestly I don't think using "select " or "select *" is a big speed difference - it's more like the ultimate fine tuning. I think dramatic results can be achieved by developing a table layout/imap logic that minimizes the number of queries and the amount of parsing done by the imap server. On Tue, 2002-09-24 at 18:55, Ryan Butler wrote: > On Tue, 2002-09-24 at 10:48, Sam Przyswa wrote: > > > >Unless your program is getting back the rows as name value pairs and > > >picking > > through what gets sent back, you want to be specifying the columns and the > > order > > that they are to be sent back, not asking for everything and assuming that > > the > > order and number of the fields is what you think might be there. > > > > Sure it's easiest to SELECT named fields as SELECT * and use raw[x] to get > > the > > value. Our main goal it's to speed up DBmail and any suggestions are > > welcome ! > > > > That is not the easiest method, because unless you're getting it as an > associative array (name/val pairs, etc) Then you have no idea if raw[4] > is really what you expect on every installation (someone may have added > a field they need to the table). That is why the inserts and selects > only ask for the columns they need in the order they need. So that the > underlying table can be changed and not botch the whole system. > > > ___ > Dbmail mailing list > Dbmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail signature.asc Description: This is a digitally signed message part
Re: [Dbmail] Imapd is slow as hell
Parsing is definitely the issue. I wrote a very simple Python application to parse headers in my dbmail inbox - a run against 50 messages takes about 4 seconds on a very fast box, using standard Python libraries. The question is, what's more important - message insertion or subsequent processing. My vote is that subsequent processing (each access by a web mail, pop or IMAP client) is more important since they are 1 plus n accesses to the data, whereas insertion is a one time thing. In the short term a web mail client could use the 'seen' flag - parse the messages and write to its own tables to contain the header fields of interest, but, would be nice to see dbmail 2.0 do this on message insertion. Then watch imap fly! At 07:14 PM 9/24/2002 +0200, you wrote: Honestly I don't think using "select " or "select *" is a big speed difference - it's more like the ultimate fine tuning. I think dramatic results can be achieved by developing a table layout/imap logic that minimizes the number of queries and the amount of parsing done by the imap server. On Tue, 2002-09-24 at 18:55, Ryan Butler wrote: > On Tue, 2002-09-24 at 10:48, Sam Przyswa wrote: > > > >Unless your program is getting back the rows as name value pairs and picking > > through what gets sent back, you want to be specifying the columns and the order > > that they are to be sent back, not asking for everything and assuming that the > > order and number of the fields is what you think might be there. > > > > Sure it's easiest to SELECT named fields as SELECT * and use raw[x] to get the > > value. Our main goal it's to speed up DBmail and any suggestions are welcome ! > > > > That is not the easiest method, because unless you're getting it as an > associative array (name/val pairs, etc) Then you have no idea if raw[4] > is really what you expect on every installation (someone may have added > a field they need to the table). That is why the inserts and selects > only ask for the columns they need in the order they need. So that the > underlying table can be changed and not botch the whole system. > > > ___ > Dbmail mailing list > Dbmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail
Re: [Dbmail] Imapd is slow as hell
On 25/9/02 4:21 AM, "Roel Rozendaal" <[EMAIL PROTECTED]> wrote: > The basic layout for dbmail was based upon pop3 but we are interested in > better schemes for imap. One of the main goals right now is to have the > fastest imap server around. Better table layouts would mean a great > improvement; just don't know how much time will be involved in > implementing those. > Things to do right now in my opinion are to fix annoying bugs and update > the package with the several patches we have to release a STABLE 1.0 > version asap. One annoying bug I've notices is the mis-match between the status and flag_read fields. When you use POP and keep messages on server, all the messages are set to be read by setting status to 02. However, Imap only seems to look at the flag_read field, which is not updated by the POP session. Suggest either syncing the two fields, or at least getting rid of flag_read. /Mark
[Dbmail] Additional wishlist
+ Purging deleted messages based on a time different: Currently status is set to 03 meaning deleted. This allows the dbmail-maintenance script to clear all deleted messages each night or whenever the script is run. If this field could be changed to a timestamp (or treated as a timestamp, where values > 1000 = delete time, 0-2 = normal flags). /Mark
[Dbmail] Pop locks
Just checking so I can brief our helpdesk, I'm assuming dbmail does not lock the pop sessions to prohibit the same user from relogging in while another session is active. >From my tests, it looks like any destructive change (eg deleting a message Status: O is honoured immediately upon a client exiting...) Is this right? /Mark
