Fast imap server for larger foldersFast search for IMAP?migrating email public folders from cyrus imap to exchange 2010Migrating Outlook PSTs -> Maildir via IMAPFast way of copying IMAP to IMAP on CentOSDefault permissions for courier imap foldersMaintain email timestamp when transferring between email servers using an email clientIMAP server can't read (open) mails using fetchmail, procmail & dovecotEscaping Double Quotes in IMAP Search StringThunderbird sub folders grayed out after migrating to new mail server (postfix,dovecot,docker)Dovecot imap send spam to junk
Generate basis elements of the Steenrod algebra
Which languages would be most useful in Europe at the end of the 19th century?
Non-aqueous eyes?
Is it possible for a vehicle to be manufactured without a catalytic converter?
Who enforces MPAA rating adherence?
Does the 2019 UA Artificer's Many-Handed Pouch infusion enable unlimited infinite-range cross-planar communication?
Entire circuit dead after GFCI outlet
Wooden cooking layout
Can a catering trolley removal result in a measurable reduction in emissions?
Overlapping String-Blocks
How to trick the reader into thinking they're following a redshirt instead of the protagonist?
Cascading Switches. Will it affect performance?
Live action TV show where High school Kids go into the virtual world and have to clear levels
Second (easy access) account in case my bank screws up
60s or 70s novel about Empire of Man making 1st contact with 1st discovered alien race
Single-key teletype?
How did old MS-DOS games utilize various graphic cards?
How to communicate to my GM that not being allowed to use stealth isn't fun for me?
How does the Around command at zero work?
Is an entry level DSLR going to shoot nice portrait pictures?
How to handle (one's own) self-harm scars (on the arm), in a work environment?
Traversing Oceania: A Cryptic Journey
What aircraft was used as Air Force One for the flight between Southampton and Shannon?
What is the color of artificial intelligence?
Fast imap server for larger folders
Fast search for IMAP?migrating email public folders from cyrus imap to exchange 2010Migrating Outlook PSTs -> Maildir via IMAPFast way of copying IMAP to IMAP on CentOSDefault permissions for courier imap foldersMaintain email timestamp when transferring between email servers using an email clientIMAP server can't read (open) mails using fetchmail, procmail & dovecotEscaping Double Quotes in IMAP Search StringThunderbird sub folders grayed out after migrating to new mail server (postfix,dovecot,docker)Dovecot imap send spam to junk
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
I'm looking for an imap server that is fast with larger folders. Say 20'000-100'000 emails per folder.
Currently I'm using dovecot, and opening a folder can take 10 seconds, and the HD light on the imap server is brinking like crazy.
I'm using alpine as a client, and it only lists the newest mails by default, so it's not that my client is trying to transfer everything when opening the mailbox. This can be seen in that when I scroll it has to load the subject lines for the next page (the first time I scroll there).
I'm using maildir on XFS.
Edit: I ask since it's not much data, in the grand scheme of things. If this was in a SQL database then getting the subject lines of the newest 40 messages would not take 10 seconds for a folder of 40'000 emails. The only data needed is:
SELECT date, from, subject FROM emails ORDER BY date DESC LIMIT 40;
Any ideas?
linux imap
add a comment |
I'm looking for an imap server that is fast with larger folders. Say 20'000-100'000 emails per folder.
Currently I'm using dovecot, and opening a folder can take 10 seconds, and the HD light on the imap server is brinking like crazy.
I'm using alpine as a client, and it only lists the newest mails by default, so it's not that my client is trying to transfer everything when opening the mailbox. This can be seen in that when I scroll it has to load the subject lines for the next page (the first time I scroll there).
I'm using maildir on XFS.
Edit: I ask since it's not much data, in the grand scheme of things. If this was in a SQL database then getting the subject lines of the newest 40 messages would not take 10 seconds for a folder of 40'000 emails. The only data needed is:
SELECT date, from, subject FROM emails ORDER BY date DESC LIMIT 40;
Any ideas?
linux imap
I would suggest splitting these folders up. It will be nicer for the user and for the server.
– alex
Nov 26 '09 at 22:53
I'm the user, and no it wouldn't be. It's the ugly fix I'm going with though.
– Thomas
Nov 27 '09 at 17:35
add a comment |
I'm looking for an imap server that is fast with larger folders. Say 20'000-100'000 emails per folder.
Currently I'm using dovecot, and opening a folder can take 10 seconds, and the HD light on the imap server is brinking like crazy.
I'm using alpine as a client, and it only lists the newest mails by default, so it's not that my client is trying to transfer everything when opening the mailbox. This can be seen in that when I scroll it has to load the subject lines for the next page (the first time I scroll there).
I'm using maildir on XFS.
Edit: I ask since it's not much data, in the grand scheme of things. If this was in a SQL database then getting the subject lines of the newest 40 messages would not take 10 seconds for a folder of 40'000 emails. The only data needed is:
SELECT date, from, subject FROM emails ORDER BY date DESC LIMIT 40;
Any ideas?
linux imap
I'm looking for an imap server that is fast with larger folders. Say 20'000-100'000 emails per folder.
Currently I'm using dovecot, and opening a folder can take 10 seconds, and the HD light on the imap server is brinking like crazy.
I'm using alpine as a client, and it only lists the newest mails by default, so it's not that my client is trying to transfer everything when opening the mailbox. This can be seen in that when I scroll it has to load the subject lines for the next page (the first time I scroll there).
I'm using maildir on XFS.
Edit: I ask since it's not much data, in the grand scheme of things. If this was in a SQL database then getting the subject lines of the newest 40 messages would not take 10 seconds for a folder of 40'000 emails. The only data needed is:
SELECT date, from, subject FROM emails ORDER BY date DESC LIMIT 40;
Any ideas?
linux imap
linux imap
edited Aug 24 '09 at 12:28
Thomas
asked Aug 24 '09 at 8:53
ThomasThomas
1,3361014
1,3361014
I would suggest splitting these folders up. It will be nicer for the user and for the server.
– alex
Nov 26 '09 at 22:53
I'm the user, and no it wouldn't be. It's the ugly fix I'm going with though.
– Thomas
Nov 27 '09 at 17:35
add a comment |
I would suggest splitting these folders up. It will be nicer for the user and for the server.
– alex
Nov 26 '09 at 22:53
I'm the user, and no it wouldn't be. It's the ugly fix I'm going with though.
– Thomas
Nov 27 '09 at 17:35
I would suggest splitting these folders up. It will be nicer for the user and for the server.
– alex
Nov 26 '09 at 22:53
I would suggest splitting these folders up. It will be nicer for the user and for the server.
– alex
Nov 26 '09 at 22:53
I'm the user, and no it wouldn't be. It's the ugly fix I'm going with though.
– Thomas
Nov 27 '09 at 17:35
I'm the user, and no it wouldn't be. It's the ugly fix I'm going with though.
– Thomas
Nov 27 '09 at 17:35
add a comment |
4 Answers
4
active
oldest
votes
Dovecot is actually pretty good, performance-wise. Dovecot's Performance Tuning wiki page has a few tips and tricks to further improve performance. Keeping indices and maildirs on separate disks is a good thing to start with, if at all possible for you. You could also evaluate switching to Dovecot's dbox storage format.
I've tried to optimize using the tuning page. This is as good as I got it. I'll try dbox.
– Thomas
Aug 24 '09 at 12:31
dovecot is bonkers fast
– hendry
Feb 2 '12 at 16:18
add a comment |
Maybe you could try using a database engine for message storage, instead of using Maildir/Maildir++ mailboxes. This can be done with dbmail.
I don't know how reliable dbmail is for a production environment, but since you already have virtualization working, you could set it up on another VM for testing purposes and see how it performs on your environment.
Here's an overview of dbmail's architecture:
(source: dbmail.org)
I don't think that the graphic adds any value to the otherwise nice answer. There's also an interesting thread on the dovecot mailing list, benchmarking some aspects of dovecot vs dbmail (dovecot.org/list/dovecot/2007-May/022599.html).
– earl
Aug 24 '09 at 17:42
Earl, thanks for the feedback. I think that the OP mileage might vary, and that's why it would be useful for him to perform some tests on his own environment. It's not my intention to question the value of the benchmarks that you linked, but since those tests were run 2.5 years (and 6 releases) ago, it wouldn't be a bad idea to check again.
– mfriedman
Aug 24 '09 at 18:29
Oh, and regarding the diagram that I've added to my answer, I respectfully disagree. It shows how the pieces fit together, what are the DBMail and the Non-DBMail components, and how they interact with each other. Even when I agree that the picture may be beyond what was asked, I think that it helps to illustrate how this particular solution works. And, as the saying goes, "a picture is worth a thousand words". Best regards, Marcus.
– mfriedman
Aug 24 '09 at 18:35
Thank you for the link and diagram. I have done some subjective "feel" benchmarking and it seems that dovecot is slightly faster once it has cached the index, but since emails keep trickling in the cache is soon invalidated so in practice I get the slow hit every time I open the mailbox. dbmail seems to take the hit incrementally on email insertion (makes sense), so it's while it may not be quite as fast, I never get the 10s wait to open a folder. Tested with 44'000 emails in a box.
– Thomas
Aug 24 '09 at 21:25
add a comment |
You don't mention the server specs...how much memory are you using, processor, network card/switches are gigabit? And if you look at the server, can you tell what's being maxed out? If it's drive throughput you aren't going to get very far changing the server software
I've been cloning systems over a network and was puzzled to have two systems on a gigabit switch pulling only about 15 MB/sec when I knew that my system was capable of bursts in the 50 MB/s range. Turned out it was the disks bottlenecking on the end-systems (I put a drive into a second IDE channel and did a direct DD, got the same transfer speeds).
You might want to check out the processor/disk/network usage as well as the switch and see if any of those are causing issues. If not those, you could look for ways to boost throughput using separate disks, separating mailboxes to different spindles, check and see if you can get any better throughput using hardware RAID mirroring (I'm not sure how much of a boost in read times off the disks you can get), or possibly moving to higher-performing hard disks with lower latency and bigger caches.
My point is that it's not much data. 40'000 entries is nothing to a database. It shouldn't be much for an imap server. It's a virtual machine (KVM on Linux) on a quad-core 2.4GHz with raid5 and 8GB RAM, but I've seen this on a physical machine as well. I've benchmarked the disks and network and I get about than 100MByte/sec. But remember that all this is just reading select mail headers (from, flags, subject) of about 40 (the latest) of 40'000 emails. Not even the 40 mail bodies.
– Thomas
Aug 24 '09 at 12:22
And not 40'000 mail headers. They are loaded on demand if I scroll.
– Thomas
Aug 24 '09 at 12:23
You probably already checked this (nice specs on the server...shouldn't be that is the issue, I'd think) but is it possibly the client system reading the locally cached information and going back and forth that is causing some slowdown?
– Bart Silverstrim
Aug 24 '09 at 12:35
add a comment |
Since you're using dovecot I presume you're already using it's indexing features? I'm not aware of anything (at least, not anything free), that's faster than dovecot.
Yes, I'm using the indexing. The thing that confuses me is that an SQL database would not take 10 seconds to list the newest 40 rows (when properly indexed). I've updated the question with this.
– Thomas
Aug 24 '09 at 12:16
add a comment |
protected by sysadmin1138♦ Feb 4 '16 at 16:46
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Dovecot is actually pretty good, performance-wise. Dovecot's Performance Tuning wiki page has a few tips and tricks to further improve performance. Keeping indices and maildirs on separate disks is a good thing to start with, if at all possible for you. You could also evaluate switching to Dovecot's dbox storage format.
I've tried to optimize using the tuning page. This is as good as I got it. I'll try dbox.
– Thomas
Aug 24 '09 at 12:31
dovecot is bonkers fast
– hendry
Feb 2 '12 at 16:18
add a comment |
Dovecot is actually pretty good, performance-wise. Dovecot's Performance Tuning wiki page has a few tips and tricks to further improve performance. Keeping indices and maildirs on separate disks is a good thing to start with, if at all possible for you. You could also evaluate switching to Dovecot's dbox storage format.
I've tried to optimize using the tuning page. This is as good as I got it. I'll try dbox.
– Thomas
Aug 24 '09 at 12:31
dovecot is bonkers fast
– hendry
Feb 2 '12 at 16:18
add a comment |
Dovecot is actually pretty good, performance-wise. Dovecot's Performance Tuning wiki page has a few tips and tricks to further improve performance. Keeping indices and maildirs on separate disks is a good thing to start with, if at all possible for you. You could also evaluate switching to Dovecot's dbox storage format.
Dovecot is actually pretty good, performance-wise. Dovecot's Performance Tuning wiki page has a few tips and tricks to further improve performance. Keeping indices and maildirs on separate disks is a good thing to start with, if at all possible for you. You could also evaluate switching to Dovecot's dbox storage format.
edited Aug 24 '09 at 9:07
answered Aug 24 '09 at 9:01
earlearl
2,5611816
2,5611816
I've tried to optimize using the tuning page. This is as good as I got it. I'll try dbox.
– Thomas
Aug 24 '09 at 12:31
dovecot is bonkers fast
– hendry
Feb 2 '12 at 16:18
add a comment |
I've tried to optimize using the tuning page. This is as good as I got it. I'll try dbox.
– Thomas
Aug 24 '09 at 12:31
dovecot is bonkers fast
– hendry
Feb 2 '12 at 16:18
I've tried to optimize using the tuning page. This is as good as I got it. I'll try dbox.
– Thomas
Aug 24 '09 at 12:31
I've tried to optimize using the tuning page. This is as good as I got it. I'll try dbox.
– Thomas
Aug 24 '09 at 12:31
dovecot is bonkers fast
– hendry
Feb 2 '12 at 16:18
dovecot is bonkers fast
– hendry
Feb 2 '12 at 16:18
add a comment |
Maybe you could try using a database engine for message storage, instead of using Maildir/Maildir++ mailboxes. This can be done with dbmail.
I don't know how reliable dbmail is for a production environment, but since you already have virtualization working, you could set it up on another VM for testing purposes and see how it performs on your environment.
Here's an overview of dbmail's architecture:
(source: dbmail.org)
I don't think that the graphic adds any value to the otherwise nice answer. There's also an interesting thread on the dovecot mailing list, benchmarking some aspects of dovecot vs dbmail (dovecot.org/list/dovecot/2007-May/022599.html).
– earl
Aug 24 '09 at 17:42
Earl, thanks for the feedback. I think that the OP mileage might vary, and that's why it would be useful for him to perform some tests on his own environment. It's not my intention to question the value of the benchmarks that you linked, but since those tests were run 2.5 years (and 6 releases) ago, it wouldn't be a bad idea to check again.
– mfriedman
Aug 24 '09 at 18:29
Oh, and regarding the diagram that I've added to my answer, I respectfully disagree. It shows how the pieces fit together, what are the DBMail and the Non-DBMail components, and how they interact with each other. Even when I agree that the picture may be beyond what was asked, I think that it helps to illustrate how this particular solution works. And, as the saying goes, "a picture is worth a thousand words". Best regards, Marcus.
– mfriedman
Aug 24 '09 at 18:35
Thank you for the link and diagram. I have done some subjective "feel" benchmarking and it seems that dovecot is slightly faster once it has cached the index, but since emails keep trickling in the cache is soon invalidated so in practice I get the slow hit every time I open the mailbox. dbmail seems to take the hit incrementally on email insertion (makes sense), so it's while it may not be quite as fast, I never get the 10s wait to open a folder. Tested with 44'000 emails in a box.
– Thomas
Aug 24 '09 at 21:25
add a comment |
Maybe you could try using a database engine for message storage, instead of using Maildir/Maildir++ mailboxes. This can be done with dbmail.
I don't know how reliable dbmail is for a production environment, but since you already have virtualization working, you could set it up on another VM for testing purposes and see how it performs on your environment.
Here's an overview of dbmail's architecture:
(source: dbmail.org)
I don't think that the graphic adds any value to the otherwise nice answer. There's also an interesting thread on the dovecot mailing list, benchmarking some aspects of dovecot vs dbmail (dovecot.org/list/dovecot/2007-May/022599.html).
– earl
Aug 24 '09 at 17:42
Earl, thanks for the feedback. I think that the OP mileage might vary, and that's why it would be useful for him to perform some tests on his own environment. It's not my intention to question the value of the benchmarks that you linked, but since those tests were run 2.5 years (and 6 releases) ago, it wouldn't be a bad idea to check again.
– mfriedman
Aug 24 '09 at 18:29
Oh, and regarding the diagram that I've added to my answer, I respectfully disagree. It shows how the pieces fit together, what are the DBMail and the Non-DBMail components, and how they interact with each other. Even when I agree that the picture may be beyond what was asked, I think that it helps to illustrate how this particular solution works. And, as the saying goes, "a picture is worth a thousand words". Best regards, Marcus.
– mfriedman
Aug 24 '09 at 18:35
Thank you for the link and diagram. I have done some subjective "feel" benchmarking and it seems that dovecot is slightly faster once it has cached the index, but since emails keep trickling in the cache is soon invalidated so in practice I get the slow hit every time I open the mailbox. dbmail seems to take the hit incrementally on email insertion (makes sense), so it's while it may not be quite as fast, I never get the 10s wait to open a folder. Tested with 44'000 emails in a box.
– Thomas
Aug 24 '09 at 21:25
add a comment |
Maybe you could try using a database engine for message storage, instead of using Maildir/Maildir++ mailboxes. This can be done with dbmail.
I don't know how reliable dbmail is for a production environment, but since you already have virtualization working, you could set it up on another VM for testing purposes and see how it performs on your environment.
Here's an overview of dbmail's architecture:
(source: dbmail.org)
Maybe you could try using a database engine for message storage, instead of using Maildir/Maildir++ mailboxes. This can be done with dbmail.
I don't know how reliable dbmail is for a production environment, but since you already have virtualization working, you could set it up on another VM for testing purposes and see how it performs on your environment.
Here's an overview of dbmail's architecture:
(source: dbmail.org)
edited May 23 at 23:12
Glorfindel
4921716
4921716
answered Aug 24 '09 at 12:49
mfriedmanmfriedman
1,60411114
1,60411114
I don't think that the graphic adds any value to the otherwise nice answer. There's also an interesting thread on the dovecot mailing list, benchmarking some aspects of dovecot vs dbmail (dovecot.org/list/dovecot/2007-May/022599.html).
– earl
Aug 24 '09 at 17:42
Earl, thanks for the feedback. I think that the OP mileage might vary, and that's why it would be useful for him to perform some tests on his own environment. It's not my intention to question the value of the benchmarks that you linked, but since those tests were run 2.5 years (and 6 releases) ago, it wouldn't be a bad idea to check again.
– mfriedman
Aug 24 '09 at 18:29
Oh, and regarding the diagram that I've added to my answer, I respectfully disagree. It shows how the pieces fit together, what are the DBMail and the Non-DBMail components, and how they interact with each other. Even when I agree that the picture may be beyond what was asked, I think that it helps to illustrate how this particular solution works. And, as the saying goes, "a picture is worth a thousand words". Best regards, Marcus.
– mfriedman
Aug 24 '09 at 18:35
Thank you for the link and diagram. I have done some subjective "feel" benchmarking and it seems that dovecot is slightly faster once it has cached the index, but since emails keep trickling in the cache is soon invalidated so in practice I get the slow hit every time I open the mailbox. dbmail seems to take the hit incrementally on email insertion (makes sense), so it's while it may not be quite as fast, I never get the 10s wait to open a folder. Tested with 44'000 emails in a box.
– Thomas
Aug 24 '09 at 21:25
add a comment |
I don't think that the graphic adds any value to the otherwise nice answer. There's also an interesting thread on the dovecot mailing list, benchmarking some aspects of dovecot vs dbmail (dovecot.org/list/dovecot/2007-May/022599.html).
– earl
Aug 24 '09 at 17:42
Earl, thanks for the feedback. I think that the OP mileage might vary, and that's why it would be useful for him to perform some tests on his own environment. It's not my intention to question the value of the benchmarks that you linked, but since those tests were run 2.5 years (and 6 releases) ago, it wouldn't be a bad idea to check again.
– mfriedman
Aug 24 '09 at 18:29
Oh, and regarding the diagram that I've added to my answer, I respectfully disagree. It shows how the pieces fit together, what are the DBMail and the Non-DBMail components, and how they interact with each other. Even when I agree that the picture may be beyond what was asked, I think that it helps to illustrate how this particular solution works. And, as the saying goes, "a picture is worth a thousand words". Best regards, Marcus.
– mfriedman
Aug 24 '09 at 18:35
Thank you for the link and diagram. I have done some subjective "feel" benchmarking and it seems that dovecot is slightly faster once it has cached the index, but since emails keep trickling in the cache is soon invalidated so in practice I get the slow hit every time I open the mailbox. dbmail seems to take the hit incrementally on email insertion (makes sense), so it's while it may not be quite as fast, I never get the 10s wait to open a folder. Tested with 44'000 emails in a box.
– Thomas
Aug 24 '09 at 21:25
I don't think that the graphic adds any value to the otherwise nice answer. There's also an interesting thread on the dovecot mailing list, benchmarking some aspects of dovecot vs dbmail (dovecot.org/list/dovecot/2007-May/022599.html).
– earl
Aug 24 '09 at 17:42
I don't think that the graphic adds any value to the otherwise nice answer. There's also an interesting thread on the dovecot mailing list, benchmarking some aspects of dovecot vs dbmail (dovecot.org/list/dovecot/2007-May/022599.html).
– earl
Aug 24 '09 at 17:42
Earl, thanks for the feedback. I think that the OP mileage might vary, and that's why it would be useful for him to perform some tests on his own environment. It's not my intention to question the value of the benchmarks that you linked, but since those tests were run 2.5 years (and 6 releases) ago, it wouldn't be a bad idea to check again.
– mfriedman
Aug 24 '09 at 18:29
Earl, thanks for the feedback. I think that the OP mileage might vary, and that's why it would be useful for him to perform some tests on his own environment. It's not my intention to question the value of the benchmarks that you linked, but since those tests were run 2.5 years (and 6 releases) ago, it wouldn't be a bad idea to check again.
– mfriedman
Aug 24 '09 at 18:29
Oh, and regarding the diagram that I've added to my answer, I respectfully disagree. It shows how the pieces fit together, what are the DBMail and the Non-DBMail components, and how they interact with each other. Even when I agree that the picture may be beyond what was asked, I think that it helps to illustrate how this particular solution works. And, as the saying goes, "a picture is worth a thousand words". Best regards, Marcus.
– mfriedman
Aug 24 '09 at 18:35
Oh, and regarding the diagram that I've added to my answer, I respectfully disagree. It shows how the pieces fit together, what are the DBMail and the Non-DBMail components, and how they interact with each other. Even when I agree that the picture may be beyond what was asked, I think that it helps to illustrate how this particular solution works. And, as the saying goes, "a picture is worth a thousand words". Best regards, Marcus.
– mfriedman
Aug 24 '09 at 18:35
Thank you for the link and diagram. I have done some subjective "feel" benchmarking and it seems that dovecot is slightly faster once it has cached the index, but since emails keep trickling in the cache is soon invalidated so in practice I get the slow hit every time I open the mailbox. dbmail seems to take the hit incrementally on email insertion (makes sense), so it's while it may not be quite as fast, I never get the 10s wait to open a folder. Tested with 44'000 emails in a box.
– Thomas
Aug 24 '09 at 21:25
Thank you for the link and diagram. I have done some subjective "feel" benchmarking and it seems that dovecot is slightly faster once it has cached the index, but since emails keep trickling in the cache is soon invalidated so in practice I get the slow hit every time I open the mailbox. dbmail seems to take the hit incrementally on email insertion (makes sense), so it's while it may not be quite as fast, I never get the 10s wait to open a folder. Tested with 44'000 emails in a box.
– Thomas
Aug 24 '09 at 21:25
add a comment |
You don't mention the server specs...how much memory are you using, processor, network card/switches are gigabit? And if you look at the server, can you tell what's being maxed out? If it's drive throughput you aren't going to get very far changing the server software
I've been cloning systems over a network and was puzzled to have two systems on a gigabit switch pulling only about 15 MB/sec when I knew that my system was capable of bursts in the 50 MB/s range. Turned out it was the disks bottlenecking on the end-systems (I put a drive into a second IDE channel and did a direct DD, got the same transfer speeds).
You might want to check out the processor/disk/network usage as well as the switch and see if any of those are causing issues. If not those, you could look for ways to boost throughput using separate disks, separating mailboxes to different spindles, check and see if you can get any better throughput using hardware RAID mirroring (I'm not sure how much of a boost in read times off the disks you can get), or possibly moving to higher-performing hard disks with lower latency and bigger caches.
My point is that it's not much data. 40'000 entries is nothing to a database. It shouldn't be much for an imap server. It's a virtual machine (KVM on Linux) on a quad-core 2.4GHz with raid5 and 8GB RAM, but I've seen this on a physical machine as well. I've benchmarked the disks and network and I get about than 100MByte/sec. But remember that all this is just reading select mail headers (from, flags, subject) of about 40 (the latest) of 40'000 emails. Not even the 40 mail bodies.
– Thomas
Aug 24 '09 at 12:22
And not 40'000 mail headers. They are loaded on demand if I scroll.
– Thomas
Aug 24 '09 at 12:23
You probably already checked this (nice specs on the server...shouldn't be that is the issue, I'd think) but is it possibly the client system reading the locally cached information and going back and forth that is causing some slowdown?
– Bart Silverstrim
Aug 24 '09 at 12:35
add a comment |
You don't mention the server specs...how much memory are you using, processor, network card/switches are gigabit? And if you look at the server, can you tell what's being maxed out? If it's drive throughput you aren't going to get very far changing the server software
I've been cloning systems over a network and was puzzled to have two systems on a gigabit switch pulling only about 15 MB/sec when I knew that my system was capable of bursts in the 50 MB/s range. Turned out it was the disks bottlenecking on the end-systems (I put a drive into a second IDE channel and did a direct DD, got the same transfer speeds).
You might want to check out the processor/disk/network usage as well as the switch and see if any of those are causing issues. If not those, you could look for ways to boost throughput using separate disks, separating mailboxes to different spindles, check and see if you can get any better throughput using hardware RAID mirroring (I'm not sure how much of a boost in read times off the disks you can get), or possibly moving to higher-performing hard disks with lower latency and bigger caches.
My point is that it's not much data. 40'000 entries is nothing to a database. It shouldn't be much for an imap server. It's a virtual machine (KVM on Linux) on a quad-core 2.4GHz with raid5 and 8GB RAM, but I've seen this on a physical machine as well. I've benchmarked the disks and network and I get about than 100MByte/sec. But remember that all this is just reading select mail headers (from, flags, subject) of about 40 (the latest) of 40'000 emails. Not even the 40 mail bodies.
– Thomas
Aug 24 '09 at 12:22
And not 40'000 mail headers. They are loaded on demand if I scroll.
– Thomas
Aug 24 '09 at 12:23
You probably already checked this (nice specs on the server...shouldn't be that is the issue, I'd think) but is it possibly the client system reading the locally cached information and going back and forth that is causing some slowdown?
– Bart Silverstrim
Aug 24 '09 at 12:35
add a comment |
You don't mention the server specs...how much memory are you using, processor, network card/switches are gigabit? And if you look at the server, can you tell what's being maxed out? If it's drive throughput you aren't going to get very far changing the server software
I've been cloning systems over a network and was puzzled to have two systems on a gigabit switch pulling only about 15 MB/sec when I knew that my system was capable of bursts in the 50 MB/s range. Turned out it was the disks bottlenecking on the end-systems (I put a drive into a second IDE channel and did a direct DD, got the same transfer speeds).
You might want to check out the processor/disk/network usage as well as the switch and see if any of those are causing issues. If not those, you could look for ways to boost throughput using separate disks, separating mailboxes to different spindles, check and see if you can get any better throughput using hardware RAID mirroring (I'm not sure how much of a boost in read times off the disks you can get), or possibly moving to higher-performing hard disks with lower latency and bigger caches.
You don't mention the server specs...how much memory are you using, processor, network card/switches are gigabit? And if you look at the server, can you tell what's being maxed out? If it's drive throughput you aren't going to get very far changing the server software
I've been cloning systems over a network and was puzzled to have two systems on a gigabit switch pulling only about 15 MB/sec when I knew that my system was capable of bursts in the 50 MB/s range. Turned out it was the disks bottlenecking on the end-systems (I put a drive into a second IDE channel and did a direct DD, got the same transfer speeds).
You might want to check out the processor/disk/network usage as well as the switch and see if any of those are causing issues. If not those, you could look for ways to boost throughput using separate disks, separating mailboxes to different spindles, check and see if you can get any better throughput using hardware RAID mirroring (I'm not sure how much of a boost in read times off the disks you can get), or possibly moving to higher-performing hard disks with lower latency and bigger caches.
answered Aug 24 '09 at 12:07
Bart SilverstrimBart Silverstrim
29.5k95684
29.5k95684
My point is that it's not much data. 40'000 entries is nothing to a database. It shouldn't be much for an imap server. It's a virtual machine (KVM on Linux) on a quad-core 2.4GHz with raid5 and 8GB RAM, but I've seen this on a physical machine as well. I've benchmarked the disks and network and I get about than 100MByte/sec. But remember that all this is just reading select mail headers (from, flags, subject) of about 40 (the latest) of 40'000 emails. Not even the 40 mail bodies.
– Thomas
Aug 24 '09 at 12:22
And not 40'000 mail headers. They are loaded on demand if I scroll.
– Thomas
Aug 24 '09 at 12:23
You probably already checked this (nice specs on the server...shouldn't be that is the issue, I'd think) but is it possibly the client system reading the locally cached information and going back and forth that is causing some slowdown?
– Bart Silverstrim
Aug 24 '09 at 12:35
add a comment |
My point is that it's not much data. 40'000 entries is nothing to a database. It shouldn't be much for an imap server. It's a virtual machine (KVM on Linux) on a quad-core 2.4GHz with raid5 and 8GB RAM, but I've seen this on a physical machine as well. I've benchmarked the disks and network and I get about than 100MByte/sec. But remember that all this is just reading select mail headers (from, flags, subject) of about 40 (the latest) of 40'000 emails. Not even the 40 mail bodies.
– Thomas
Aug 24 '09 at 12:22
And not 40'000 mail headers. They are loaded on demand if I scroll.
– Thomas
Aug 24 '09 at 12:23
You probably already checked this (nice specs on the server...shouldn't be that is the issue, I'd think) but is it possibly the client system reading the locally cached information and going back and forth that is causing some slowdown?
– Bart Silverstrim
Aug 24 '09 at 12:35
My point is that it's not much data. 40'000 entries is nothing to a database. It shouldn't be much for an imap server. It's a virtual machine (KVM on Linux) on a quad-core 2.4GHz with raid5 and 8GB RAM, but I've seen this on a physical machine as well. I've benchmarked the disks and network and I get about than 100MByte/sec. But remember that all this is just reading select mail headers (from, flags, subject) of about 40 (the latest) of 40'000 emails. Not even the 40 mail bodies.
– Thomas
Aug 24 '09 at 12:22
My point is that it's not much data. 40'000 entries is nothing to a database. It shouldn't be much for an imap server. It's a virtual machine (KVM on Linux) on a quad-core 2.4GHz with raid5 and 8GB RAM, but I've seen this on a physical machine as well. I've benchmarked the disks and network and I get about than 100MByte/sec. But remember that all this is just reading select mail headers (from, flags, subject) of about 40 (the latest) of 40'000 emails. Not even the 40 mail bodies.
– Thomas
Aug 24 '09 at 12:22
And not 40'000 mail headers. They are loaded on demand if I scroll.
– Thomas
Aug 24 '09 at 12:23
And not 40'000 mail headers. They are loaded on demand if I scroll.
– Thomas
Aug 24 '09 at 12:23
You probably already checked this (nice specs on the server...shouldn't be that is the issue, I'd think) but is it possibly the client system reading the locally cached information and going back and forth that is causing some slowdown?
– Bart Silverstrim
Aug 24 '09 at 12:35
You probably already checked this (nice specs on the server...shouldn't be that is the issue, I'd think) but is it possibly the client system reading the locally cached information and going back and forth that is causing some slowdown?
– Bart Silverstrim
Aug 24 '09 at 12:35
add a comment |
Since you're using dovecot I presume you're already using it's indexing features? I'm not aware of anything (at least, not anything free), that's faster than dovecot.
Yes, I'm using the indexing. The thing that confuses me is that an SQL database would not take 10 seconds to list the newest 40 rows (when properly indexed). I've updated the question with this.
– Thomas
Aug 24 '09 at 12:16
add a comment |
Since you're using dovecot I presume you're already using it's indexing features? I'm not aware of anything (at least, not anything free), that's faster than dovecot.
Yes, I'm using the indexing. The thing that confuses me is that an SQL database would not take 10 seconds to list the newest 40 rows (when properly indexed). I've updated the question with this.
– Thomas
Aug 24 '09 at 12:16
add a comment |
Since you're using dovecot I presume you're already using it's indexing features? I'm not aware of anything (at least, not anything free), that's faster than dovecot.
Since you're using dovecot I presume you're already using it's indexing features? I'm not aware of anything (at least, not anything free), that's faster than dovecot.
answered Aug 24 '09 at 8:56
theotherreceivetheotherreceive
7,61712543
7,61712543
Yes, I'm using the indexing. The thing that confuses me is that an SQL database would not take 10 seconds to list the newest 40 rows (when properly indexed). I've updated the question with this.
– Thomas
Aug 24 '09 at 12:16
add a comment |
Yes, I'm using the indexing. The thing that confuses me is that an SQL database would not take 10 seconds to list the newest 40 rows (when properly indexed). I've updated the question with this.
– Thomas
Aug 24 '09 at 12:16
Yes, I'm using the indexing. The thing that confuses me is that an SQL database would not take 10 seconds to list the newest 40 rows (when properly indexed). I've updated the question with this.
– Thomas
Aug 24 '09 at 12:16
Yes, I'm using the indexing. The thing that confuses me is that an SQL database would not take 10 seconds to list the newest 40 rows (when properly indexed). I've updated the question with this.
– Thomas
Aug 24 '09 at 12:16
add a comment |
protected by sysadmin1138♦ Feb 4 '16 at 16:46
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
I would suggest splitting these folders up. It will be nicer for the user and for the server.
– alex
Nov 26 '09 at 22:53
I'm the user, and no it wouldn't be. It's the ugly fix I'm going with though.
– Thomas
Nov 27 '09 at 17:35