Hi all, since I install the 0.3 stable read mailbox was very slow. The sended folder have 3000 messages and I must wait 80 sec with 20 records per page. My inbox have 700 messages and I wait 3 seconds (this is ok... I am on google imap).
Have u changed something? I need some configuration?
Thanks
Sandro Pazzi wrote:
since I install the 0.3 stable read mailbox was very slow. The sended folder have 3000 messages and I must wait 80 sec with 20 records per page. My inbox have 700 messages and I wait 3 seconds (this is ok... I am on google imap).
Have u changed something? I need some configuration?
Yes and No. In 0.3 messages sorting has been fixed for servers without SORT capability. Because Roundcube currently does not support sorting by message index (never did), sorting is "required", it's not possible to use default messages order. To sort messages in this case we need to fetch headers of all messages. This is slow. For servers without SORT, the only solution would be to implement "sorting by message index" in Roundcube.
Hi alec, this is not very clear for me but in this way the rc is not utilizable. The functionality of 0.2 was fine for me... It's not possible let user choose with the configuration file if implement or not?
Or in another way u must work most with the db and make sorting with db and not imap.
Hope a fast solution.
Thanks
On Mon, 07 Sep 2009 12:15:06 +0200, "A.L.E.C" alec@alec.pl wrote:
Sandro Pazzi wrote:
since I install the 0.3 stable read mailbox was very slow. The sended folder have 3000 messages and I must wait 80 sec with 20 records per page. My inbox have 700 messages and I wait 3 seconds (this is ok... I am on google imap).
Have u changed something? I need some configuration?
Yes and No. In 0.3 messages sorting has been fixed for servers without SORT capability. Because Roundcube currently does not support sorting by
message index (never did), sorting is "required", it's not possible to use default messages order. To sort messages in this case we need to fetch headers of all messages. This is slow. For servers without SORT, the only solution would be to implement "sorting by message index" in Roundcube.
Sandro Pazzi wrote:
Hi alec, this is not very clear for me but in this way the rc is not utilizable. The functionality of 0.2 was fine for me... It's not possible let user choose with the configuration file if implement or not?
No. In 0.2 it was quick, because it was buggy.
Or in another way u must work most with the db and make sorting with db and not imap.
Did you try with enable_caching = true?
Hope a fast solution.
There's no fast solution, maybe we'll work on "default sorting" in 0.4.
Hi Sandro,
On 2009-09-07 18:35, Sandro Pazzi wrote:
this is not very clear for me but in this way the rc is not utilizable. The functionality of 0.2 was fine for me... It's not possible let user choose with the configuration file if implement or not?
Or in another way u must work most with the db and make sorting with db and not imap.
Hope a fast solution.
You can always switch to an IMAP server that supports sorting - for example the excellent dovecot. It will be very fast then.
Patrick.
Hi Alec, the enable_caching was true but not all messages was saved in the db. If u mast read all the headers why not register all in the db? In this way it's was slow only the first time.
I love the 0.2 sorting bug :). Tell me how to reproduce this bug becouse was perfect for me.
Thanks
On Mon, 07 Sep 2009 12:35:35 +0200, "A.L.E.C" alec@alec.pl wrote:
Sandro Pazzi wrote:
Hi alec, this is not very clear for me but in this way the rc is not utilizable. The functionality of 0.2 was fine for me... It's not possible let user choose with the configuration file if implement or not?
No. In 0.2 it was quick, because it was buggy.
Or in another way u must work most with the db and make sorting with db and not imap.
Did you try with enable_caching = true?
Hope a fast solution.
There's no fast solution, maybe we'll work on "default sorting" in 0.4.
Hi Alec, I have reinstalled the 0.2. This work fine for me. Can u please tell me what I must change in 0.3 to have the same performance that 0.2 have (also if this is a bug).
Thanks.
On Mon, 07 Sep 2009 12:35:35 +0200, "A.L.E.C" alec@alec.pl wrote:
Sandro Pazzi wrote:
Hi alec, this is not very clear for me but in this way the rc is not utilizable. The functionality of 0.2 was fine for me... It's not possible let user choose with the configuration file if implement or not?
No. In 0.2 it was quick, because it was buggy.
Or in another way u must work most with the db and make sorting with db and not imap.
Did you try with enable_caching = true?
Hope a fast solution.
There's no fast solution, maybe we'll work on "default sorting" in 0.4.
Sandro Pazzi wrote:
Hi Alec, I have reinstalled the 0.2. This work fine for me. Can u please tell me what I must change in 0.3 to have the same performance that 0.2 have (also if this is a bug).
Sorry, there was too many changes in the code. You should probably look at this patchset http://trac.roundcube.net/changeset?new=2632%40trunk%2Froundcubemail%2Fprogr...
Hi Patrick, probably google not support the sorting, but change the mail server because rc 0.3 was slow seems a drastic solution. Now I reinstall the 0.2 2501 and it work fast.
If was a bug give me a 0.3 version with this bug :)
Thanks and see u
On Mon, 07 Sep 2009 18:44:01 +0800, Patrick Nagel mail@patrick-nagel.net wrote:
Hi Sandro,
On 2009-09-07 18:35, Sandro Pazzi wrote:
this is not very clear for me but in this way the rc is not utilizable. The functionality of 0.2 was fine for me... It's not possible let user choose with the configuration file if implement or not?
Or in another way u must work most with the db and make sorting with db and not imap.
Hope a fast solution.
You can always switch to an IMAP server that supports sorting - for
example
the excellent dovecot. It will be very fast then.
Patrick.
Hi Sandro! Maybe it's not so drstic to change a bad solution to a good one. If you are using a Fiat 600 (google IMAP) and it's slow on highways (Roundcube), ¿what will you change: the car or the highway? Yes, Fiat is fast enough on down hills, but maybe Ferrai (Dovecot) is also faster on uphills.
Think about it... emi
2009/9/7 Sandro Pazzi sandro@idweb.it
Hi Patrick, probably google not support the sorting, but change the mail server because rc 0.3 was slow seems a drastic solution. Now I reinstall the 0.2 2501 and it work fast.
If was a bug give me a 0.3 version with this bug :)
Thanks and see u
On Mon, 07 Sep 2009 18:44:01 +0800, Patrick Nagel mail@patrick-nagel.net wrote:
Hi Sandro,
On 2009-09-07 18:35, Sandro Pazzi wrote:
this is not very clear for me but in this way the rc is not utilizable. The functionality of 0.2 was fine for me... It's not possible let user choose with the configuration file if implement or not?
Or in another way u must work most with the db and make sorting with db and not imap.
Hope a fast solution.
You can always switch to an IMAP server that supports sorting - for
example
the excellent dovecot. It will be very fast then.
Patrick.
-- Sandro Pazzi
IdWeb s.r.l. Viale Romagna 69/A - 06012 Citta' di Castello (PG) Tel. 075 851 97 28 Fax 075 851 97 30 _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Hi all, probably u was right but I can't change google for other reasons. The thing that I was saying is that rc 0.2 works great also in the terrible google imap service and I have not notice any bug.
Now with the 0.3 rc was slow in google having fix a bug for imap support sorting. I love the idea that the rc 0.3 works more fast on imap servers supporting sorting but i'd like that have the same performance of 0.2 in that server that does not support sorting functionality.
Thanks at all
On Mon, 7 Sep 2009 14:36:18 +0200, emi emidaruma@gmail.com wrote:
Hi Sandro! Maybe it's not so drstic to change a bad solution to a good one. If you
are
using a Fiat 600 (google IMAP) and it's slow on highways (Roundcube), ¿what will you change: the car or the highway? Yes, Fiat is fast enough on down hills, but maybe Ferrai (Dovecot) is also faster on uphills.
Think about it... emi
2009/9/7 Sandro Pazzi sandro@idweb.it
Hi Patrick, probably google not support the sorting, but change the mail server because rc 0.3 was slow seems a drastic solution. Now I reinstall the 0.2 2501 and it work fast.
If was a bug give me a 0.3 version with this bug :)
Thanks and see u
On Mon, 07 Sep 2009 18:44:01 +0800, Patrick Nagel mail@patrick-nagel.net wrote:
Hi Sandro,
On 2009-09-07 18:35, Sandro Pazzi wrote:
this is not very clear for me but in this way the rc is not utilizable. The functionality of 0.2 was fine for me... It's not possible let
user
choose with the configuration file if implement or not?
Or in another way u must work most with the db and make sorting with db and not imap.
Hope a fast solution.
You can always switch to an IMAP server that supports sorting - for
example
the excellent dovecot. It will be very fast then.
Patrick.
-- Sandro Pazzi
IdWeb s.r.l. Viale Romagna 69/A - 06012 Citta' di Castello (PG) Tel. 075 851 97 28 Fax 075 851 97 30 _______________________________________________ List info: http://lists.roundcube.net/dev/
On Mon, 07 Sep 2009 15:13:15 +0200, Sandro Pazzi sandro@idweb.it wrote:
Hi all, probably u was right but I can't change google for other reasons. The thing that I was saying is that rc 0.2 works great also in the
terrible
google imap service and I have not notice any bug.
Now with the 0.3 rc was slow in google having fix a bug for imap support sorting. I love the idea that the rc 0.3 works more fast on imap servers supporting sorting but i'd like that have the same performance of 0.2 in that server that does not support sorting functionality.
However, it's not necessarily gmail *OR* dovecot. They are not incompatible, you can use both in conjunction.
I use many external accounts (gmail, terra, etc) but I download all the mail locally with fetchmail, and serve it with dovecot from a centralized location. Then I can use roundcube or whatever client fits better over the local imap server which is lightning fast. It also eases backups quite a bit.
Thanks Jesús, it's possible solution. Anyway the dovecot server must be reachable anywhere with connectivity problem. I'd like the gmail service. RC was great with gmail since 0.3. I think that all my problems would be resolved with some recoding in rcube_imap class that can work like 0.2 with some configuration.
Hope in a solution.
Thanks
On Mon, 07 Sep 2009 15:52:27 +0200, Jesús Guerrero i92guboj@terra.es wrote:
On Mon, 07 Sep 2009 15:13:15 +0200, Sandro Pazzi sandro@idweb.it wrote:
Hi all, probably u was right but I can't change google for other reasons. The thing that I was saying is that rc 0.2 works great also in the
terrible
google imap service and I have not notice any bug.
Now with the 0.3 rc was slow in google having fix a bug for imap support sorting. I love the idea that the rc 0.3 works more fast on imap servers supporting sorting but i'd like that have the same performance of 0.2 in that server that does not support sorting functionality.
However, it's not necessarily gmail *OR* dovecot. They are not incompatible, you can use both in conjunction.
I use many external accounts (gmail, terra, etc) but I download all the mail locally with fetchmail, and serve it with dovecot from a centralized location. Then I can use roundcube or whatever client fits better over the local imap server which is lightning fast. It also eases backups quite a bit.
Hi all, I have modified the code in the rcube_imap.php and the performance was good. I post the code modified:
Original: $a_index = iil_C_FetchHeaderIndex($this->conn, $mailbox, "1:*", $this->sort_field, $this->skip_deleted);
if (empty($a_index))
return array();
asort($a_index); // ASC
$msg_index = array_keys($a_index);
$max = max($msg_index);
list($begin, $end) = $this->_get_message_range(count($msg_index),
$page); $msg_index = array_slice($msg_index, $begin, $end-$begin);
Modified: $max = $this->_messagecount($mailbox,'ALL',true); list($begin, $end) = $this->_get_message_range($max, $page);
$a_index = iil_C_FetchHeaderIndex($this->conn, $mailbox,
($begin+1).":".$end, $this->sort_field, $this->skip_deleted);
if (empty($a_index))
return array();
asort($a_index); // ASC
$msg_index = array_keys($a_index);
$msg_index = array_slice($msg_index, 0, $end-$begin);
Can u please check for some errors or issue?
Thanks
On Mon, 07 Sep 2009 13:43:55 +0200, "A.L.E.C" alec@alec.pl wrote:
Sandro Pazzi wrote:
Hi Alec, I have reinstalled the 0.2. This work fine for me. Can u please tell me what I must change in 0.3 to have the same performance that 0.2 have (also if this is a bug).
Sorry, there was too many changes in the code. You should probably look at this patchset
http://trac.roundcube.net/changeset?new=2632%40trunk%2Froundcubemail%2Fprogr...
Sandro Pazzi wrote:
Hi all, I have modified the code in the rcube_imap.php and the performance was good. I post the code modified:
Original: $a_index = iil_C_FetchHeaderIndex($this->conn, $mailbox, "1:*", $this->sort_field, $this->skip_deleted); list($begin, $end) = $this->_get_message_range(count($msg_index), $page);
Modified: $max = $this->_messagecount($mailbox,'ALL',true); list($begin, $end) = $this->_get_message_range($max, $page);
$a_index = iil_C_FetchHeaderIndex($this->conn, $mailbox,($begin+1).":".$end, $this->sort_field, $this->skip_deleted);
Can u please check for some errors or issue?
You don't understand. In our code we're fetching all messages headers and we're sorting them by (e.g.) date first, then we're fetching a part needed for the one list page. In your code, you're fetching only part of the list and you're sorting that part not all messages. This is not proper because "default sorting" is not "sorting by date". This sometimes would be ok, but definetly not when sorting by subject and even by date.
So, we'll not break things to get better performance.
A.L.E.C wrote:
You don't understand. In our code we're fetching all messages headers
Of course, here we're fetching date header of all messages, not all headers.
Thanks Alec, I know what u are doing with your code and also know that mine have problem.
Anyway I have not seen issue in the normal ordering in the 0.2. Probably your solution was great for complex ordering but for standard ordering fetch 5000 messages make rc unusable.
It's a possible idea to fetch all messages only for complex ordering? Or make a config variable for fast or better ordering?
I don't know the solution but if no change will be made I'll must change imap client because unusable for me.
Hope in your idea.
Thanks and sorry for diff file.
On Tue, 08 Sep 2009 13:28:21 +0200, "A.L.E.C" alec@alec.pl wrote:
Sandro Pazzi wrote:
Hi all, I have modified the code in the rcube_imap.php and the performance was good. I post the code modified:
Original: $a_index = iil_C_FetchHeaderIndex($this->conn, $mailbox, "1:*", $this->sort_field, $this->skip_deleted); list($begin, $end) = $this->_get_message_range(count($msg_index), $page);
Modified: $max = $this->_messagecount($mailbox,'ALL',true); list($begin, $end) = $this->_get_message_range($max, $page);
$a_index = iil_C_FetchHeaderIndex($this->conn, $mailbox,($begin+1).":".$end, $this->sort_field, $this->skip_deleted);
Can u please check for some errors or issue?
You don't understand. In our code we're fetching all messages headers and we're sorting them by (e.g.) date first, then we're fetching a part needed for the one list page. In your code, you're fetching only part of the list and you're sorting that part not all messages. This is not proper because "default sorting"
is not "sorting by date". This sometimes would be ok, but definetly not when sorting by subject and even by date.
So, we'll not break things to get better performance.
Sandro Pazzi wrote:
I don't know the solution but if no change will be made I'll must change imap client because unusable for me.
You need to wait until we implement sorting by message index. This is default IMAP sorting and this will be faster.
Thanks Alec, in meanwhile I take my bad solution.
Any idea on time for this implementation?
Thanks
On Tue, 08 Sep 2009 13:49:36 +0200, "A.L.E.C" alec@alec.pl wrote:
Sandro Pazzi wrote:
I don't know the solution but if no change will be made I'll must
change
imap client because unusable for me.
You need to wait until we implement sorting by message index. This is default IMAP sorting and this will be faster.
Sandro Pazzi wrote:
Any idea on time for this implementation?
No, but it's open source. Maybe you should say: "If I pay $XXX for such feature, how long I will wait?" ;)
Here's the ticket http://trac.roundcube.net/ticket/1485936
Hi Folks,
just installed roundcubemail-0.3-stable, which works fine and is a great program.
One thing annoys me, that i get in any *subfolder* of the "sent"-folder the "From"-field displayed in the list view, which is always me, and therefore not much informative. I would like to see, like in the "sent"-root-Folder, the recipient.
I fixed this by replacing line 397 in /program/steps/mail/func.inc from if (($mbox == $CONFIG['sent_mbox'] || $mbox == $CONFIG['drafts_mbox'])
to
if ((substr($mbox, 0, strlen($CONFIG['sent_mbox']))==$CONFIG['sent_mbox'] || $mbox==$CONFIG['drafts_mbox'])
Maybe you like this and transfer it.
Greetings, Cornelis Denhart (Essen, Germany) _______________________________________________ List info: http://lists.roundcube.net/dev/
-
A.L.E.C -
Cornelis Denhart -
emi -
Jesús Guerrero -
Patrick Nagel -
Sandro Pazzi