Am 27.06.2012 09:32, schrieb Wojciech Puchar:
>>
>> Hi, i dont wanna flame into this thread, cause its heavy tec stuff
>> which i dont really fit in
>>
>> but for some webmail you can use http://imapproxy.org/
>
> the discussion was about if running proxy at all make sense.
>
> Proxies are to red
Hi, i dont wanna flame into this thread, cause its heavy tec stuff
which i dont really fit in
but for some webmail you can use http://imapproxy.org/
the discussion was about if running proxy at all make sense.
Proxies are to reduce traffic or server load by avoiding repetitive
requests.
Wi
Am 27.06.2012 07:44, schrieb Wojciech Puchar:
>>
>> Timo: I'm not sure if you are saying that all client-side caching is
>> wrong. If so, I'm going to disagree with you, especially when dealing
>> with more complex data structures.
>
>
> it is always good - on WAN links.
Hi, i dont wanna flame i
Timo: I'm not sure if you are saying that all client-side caching is wrong.
If so, I'm going to disagree with you, especially when dealing with more
complex data structures.
it is always good - on WAN links.
Quoting Timo Sirainen :
Well, I had completely forgotten about it :) Reading my old mail:
There isn't a whole lot of state to be saved really. Mailbox GUID,
UIDVALIDITY,
HIGHESTMODSEQ gives the mailbox state. Then you have the
language/etc. states.
Clients could restore their earlier state
Quoting Wojciech Puchar :
It's stupid how webmail works but dovecot doesn't have a problem to
get new connections every now and then. just make sure you didn't
set up SSL by accident.
Would you mind explaining why you think it is "stupid" the way webmail
works? I assume you are angry bec
Quoting Timo Sirainen :
On 23.6.2012, at 13.21, Ed W wrote:
But I don't know, whether this is the sort of caching you are
referring to.
what's a point of caching imap, except your webmail service is not
locally connected (localhost or LAN) to imap server?
Asking for items 600-615 from a
wehre your webmail is running and configure the webmail for
using 127.0.0.1 - so only one connection per user is
persistent instead make a new one for each ajax-request
Someone benchmarked Dovecot a while ago in this list with and without imapproxy
and the results showed that imapproxy simply s
On Thu, Jun 21, 2012 at 11:44:33PM +0300, Timo Sirainen wrote:
> >
> > additionally you should install imapproxy on the webserver
> > wehre your webmail is running and configure the webmail for
> > using 127.0.0.1 - so only one connection per user is
> > persistent instead make a new one for each
Asking for items 600-615 from a threaded list, sorted by something, can be an
expensive operation, especially if you just asked for items 585-600 a moment
ago?
Can be, but is it? :) Dovecot attempts to cache/index stuff as well. Normally
there shouldn't be a need for extra caching layer exce
On 23.6.2012, at 13.21, Ed W wrote:
>>> But I don't know, whether this is the sort of caching you are referring to.
>>
>> what's a point of caching imap, except your webmail service is not locally
>> connected (localhost or LAN) to imap server?
>
> Asking for items 600-615 from a threaded list,
But I don't know, whether this is the sort of caching you are referring
to.
what's a point of caching imap, except your webmail service is not locally
connected (localhost or LAN) to imap server?
Asking for items 600-615 from a threaded list, sorted by something, can be an
expensive operatio
On 23/06/2012 09:22, Wojciech Puchar wrote:
Nearly all of them are non-caching. (I don't know of any caching ones.)
At least roundcube (v0.7.1 here) has some caching options:
--[excerpt from roundcubes main.inc.php]-
// Type of IMAP indexes cache. Supported values:
Nearly all of them are non-caching. (I don't know of any caching ones.)
At least roundcube (v0.7.1 here) has some caching options:
--[excerpt from roundcubes main.inc.php]-
// Type of IMAP indexes cache. Supported values: 'db', 'apc' and 'memcache'.
$rcmail_config['i
Nearly all of them are non-caching. (I don't know of any caching ones.)
which is definite adventage in spite of it's numerous security holes.
We are building a new system that will support a large number of users (high
volume, high concurrent usage, etc).
what is large?
We have played with Dovecot, but in most serious applications we have
traditionally used Courier IMAP.
It's my (lay) understanding that with indexing and perha
On 22.6.2012, at 8.27, email builder wrote:
> So really, a new process is created under *two* circumstances? 1. when a
> process reaches client_limit number of *simultaneous* connections or 2. when
> a process has serviced service_count number of connections. Is this correct?
Yes.
> So for se
>>> Oh, and of course it also depends on Dovecot configuration :)
>>> Authentication
>>> cache is needed and login processes must be in high performance mode.
>>
>> I.e., I think:
>>
>> http://wiki2.dovecot.org/LoginProcess
>> http://wiki2.dovecot.org/Authentication/Caching
>
> Yes.
>
>
On 22.6.2012, at 5.28, email builder wrote:
>> Oh, and of course it also depends on Dovecot configuration :) Authentication
>> cache is needed and login processes must be in high performance mode.
>
> I.e., I think:
>
> http://wiki2.dovecot.org/LoginProcess
> http://wiki2.dovecot.org/Authentica
> Oh, and of course it also depends on Dovecot configuration :) Authentication
> cache is needed and login processes must be in high performance mode.
I.e., I think:
http://wiki2.dovecot.org/LoginProcess
http://wiki2.dovecot.org/Authentication/Caching
> There is
> still the extra work of fork
On 22.6.2012, at 0.58, Michael M Slusarz wrote:
>> I think the conclusion is that imapproxy is not necessary. There are some
>> advantages (eg with high network latency between web and imap server, and
>> reducing apparent login count), and some disadvantages (extra complexity,
>> slowdown)
>
Quoting Ed W :
I think the conclusion is that imapproxy is not necessary. There
are some advantages (eg with high network latency between web and
imap server, and reducing apparent login count), and some
disadvantages (extra complexity, slowdown)
Not entirely true. See this thread:
htt
On 21/06/2012 21:37, René Neumann wrote:
Am 21.06.2012 22:22, schrieb Timo Sirainen:
On Thu, 2012-06-21 at 13:05 -0700, email builder wrote:
Do you know what webmails are caching vs. non-caching?
Nearly all of them are non-caching. (I don't know of any caching ones.)
At least roundcube (v0.7.
On 21/06/2012 21:54, Reindl Harald wrote:
and last but not least i have lesser entries in maillog which
goes to a central mysql-server for self-developed web-interfaces
I recently added imapproxy to my Roundcube installation. Benchmarks
showed a very slight slowdown, but as you point out it r
Quoting Timo Sirainen :
On Thu, 2012-06-21 at 13:05 -0700, email builder wrote:
Do you know what webmails are caching vs. non-caching?
Nearly all of them are non-caching. (I don't know of any caching ones.)
IMP is caching (message/mailbox/folder listing), with full
QRESYNC/CONDSTORE suppo
On 21.6.2012, at 23.48, Reindl Harald wrote:
>> Someone benchmarked Dovecot a while ago in this list with and without
>> imapproxy and the results showed that imapproxy simply slowed things down by
>> adding extra latency. This probably isn't true for all installations, but I
>> don't think the
Am 21.06.2012 22:52, schrieb Timo Sirainen:
> On 21.6.2012, at 23.48, Reindl Harald wrote:
>
>>> Someone benchmarked Dovecot a while ago in this list with and without
>>> imapproxy and the results showed that imapproxy simply slowed things down
>>> by adding extra latency. This probably isn't
On 21.6.2012, at 23.48, Reindl Harald wrote:
>> Someone benchmarked Dovecot a while ago in this list with and without
>> imapproxy and the results showed that imapproxy simply slowed things down by
>> adding extra latency. This probably isn't true for all installations, but I
>> don't think the
Am 21.06.2012 22:44, schrieb Timo Sirainen:
> On 21.6.2012, at 23.34, Reindl Harald wrote:
>
>> Am 21.06.2012 22:22, schrieb Timo Sirainen:
Do you know what webmails are caching vs. non-caching?
>>>
>>> Nearly all of them are non-caching. (I don't know of any caching ones.)
>>
>> roundcub
On 21.6.2012, at 23.34, Reindl Harald wrote:
> Am 21.06.2012 22:22, schrieb Timo Sirainen:
>>> Do you know what webmails are caching vs. non-caching?
>>
>> Nearly all of them are non-caching. (I don't know of any caching ones.)
>
> roundcube can if configured
>
> additionally you should insta
On Jun 21, 2012, at 3:22 PM, Timo Sirainen wrote:
> On Thu, 2012-06-21 at 13:05 -0700, email builder wrote:
>> Thank you very much for the fast reply.
>>
We are building a new system that will support a large number of users
>>
(high volume, high concurrent usage, etc). We have play
Am 21.06.2012 22:22, schrieb Timo Sirainen:
> On Thu, 2012-06-21 at 13:05 -0700, email builder wrote:
>> Do you know what webmails are caching vs. non-caching?
>
> Nearly all of them are non-caching. (I don't know of any caching ones.)
At least roundcube (v0.7.1 here) has some caching options:
Am 21.06.2012 22:22, schrieb Timo Sirainen:
>> Do you know what webmails are caching vs. non-caching?
>
> Nearly all of them are non-caching. (I don't know of any caching ones.)
roundcube can if configured
additionally you should install imapproxy on the webserver
wehre your webmail is runni
On Thu, 2012-06-21 at 13:05 -0700, email builder wrote:
> Thank you very much for the fast reply.
>
> >> We are building a new system that will support a large number of users
>
> >> (high volume, high concurrent usage, etc). We have played with Dovecot,
> >> but in
> >> most serious applica
Thank you very much for the fast reply.
>> We are building a new system that will support a large number of users
>> (high volume, high concurrent usage, etc). We have played with Dovecot, but
>> in
>> most serious applications we have traditionally used Courier IMAP. It's my
>> (lay) unde
On 21.6.2012, at 21.05, email builder wrote:
> We are building a new system that will support a large number of users (high
> volume, high concurrent usage, etc). We have played with Dovecot, but in
> most serious applications we have traditionally used Courier IMAP. It's my
> (lay) understan
Hi,
We are building a new system that will support a large number of users (high
volume, high concurrent usage, etc). We have played with Dovecot, but in most
serious applications we have traditionally used Courier IMAP. It's my (lay)
understanding that with indexing and perhaps other things
I don't see anything obviously bad in your setup. And since you said
you're running Dovecot in the IMAP server, perhaps it's not even Dovecot
at all that is causing the writes?.. Here are anyway some thoughts:
* Log files? Make sure syslog isn't fsyncing each Dovecot log line to
disk (or just set
On 11/21/2011 12:34 PM, Andy Robbins wrote:
> Warning: fd limit 1024 is lower than what Dovecot can use under full load
> (more than 2304). Either grow the limit or change login_max_processes_count
> and max_mail_processes settings
Why haven't you increased the file descriptor limit?
--
Stan
Actually, some of the information I provided previously was incorrect. We
have four mail servers in our cluster which each have the NFS share
mounted. These four servers handle all SMTP and sending of mail. However,
it was thought that we could boost performance by simply running POP3 and
IMAP dire
Am Donnerstag, 17. November 2011, 22:30:07 schrieb Andy Robbins:
> We are currently experiencing performance issue with our Dovecot
> system which we believe is caused by excessive writes to the dovecot
> files. The confusing thing is that we are seeing more writes than
> reads on our Dovecot volu
Do you have more than one Dovecot server? If only one, you can still disable
the mail_nfs_* settings. Also it would be interesting to see nfsstat numbers
from the Dovecot server, compared to those iostat numbers..
On 18.11.2011, at 0.38, Andy Robbins wrote:
> Well, the iostat command was run fr
Well, the iostat command was run from the NFS server and dovecot was run
from the mail server where it is mounted, hence the discrepancy there.
On Thu, Nov 17, 2011 at 4:34 PM, Timo Sirainen wrote:
> On 18.11.2011, at 0.20, Andy Robbins wrote:
>
> > # iostat -d 5 -x
> > Device: rrqm/s
On Thu, Nov 17, 2011 at 03:30:07PM -0600, Andy Robbins wrote:
> We are currently experiencing performance issue with our Dovecot system
> which we believe is caused by excessive writes to the dovecot files. The
> confusing thing is that we are seeing more writes than reads on our Dovecot
> volume w
On 18.11.2011, at 0.20, Andy Robbins wrote:
> # iostat -d 5 -x
> Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz
> avgqu-sz await svctm %util
> dm-4 0.00 0.00 485.80 865.80 3886.40 6926.40
> 8.0028.69 19.63 0.70 94.00
> drbd0
# dovecot -n
# 1.2.9: //etc/dovecot.conf
# OS: Linux 2.6.18-164.9.1.el5 x86_64 CentOS release 5.4 (Final)
base_dir: /var/run/dovecot/
log_path: /var/log/dovecot.log
protocols: imap pop3
ssl_cert_file: /etc/postfix/ssl/smtp1.domain.com.cert
ssl_key_file: /etc/postfix/ssl/smtp1.domain.com.key
disable
On 17.11.2011, at 23.30, Andy Robbins wrote:
> We can't figure out why we would be seeing twice as many writes as we are
> reads. Could this have something to do with the index files?
dovecot -n output would be helpful.
We are currently experiencing performance issue with our Dovecot system
which we believe is caused by excessive writes to the dovecot files. The
confusing thing is that we are seeing more writes than reads on our Dovecot
volume when you would assume that most of the IO should be reads from
customer
Hi All,
I wanted to follow up my own message from September now that I've got
more information.
As of RHEL 5.3, GFS2 was finally advertised as "production ready" and
the servers discussed below have been upgraded from GFS to GFS2. The
difference is night and day. Essentially GFS2 has completel
On Wed, Sep 24, 2008 at 9:18 PM, Diego Liziero <[EMAIL PROTECTED]> wrote:
> I've read somewhere that one of gfs2 goals was to improve performance
> for directory access with many files.
>
> I've tested it doing a simple ls in a directory with many test empty
> files in gfs and it was _really_ slow,
On Sep 24, 2008, at 10:03 PM, Allen Belletti wrote:
As best I can determine, the worst problems occur when certain users
with very large Inboxes (~10k messages) receive new mail and their
client looks up information about that message. GFS doesn't seem to
efficiently handle the large directorie
I've read somewhere that one of gfs2 goals was to improve performance
for directory access with many files.
I've tested it doing a simple ls in a directory with many test empty
files in gfs and it was _really_ slow, doing the ls on a gfs2 with the
same amount of emtpy files is actually faster.
Bu
Hello All,
We are using Dovecot 1.1.3 to serve IMAP on a pair of clustered Postfix
servers which share a fiber array via the GFS clustered filesystem.
This all works very well for the most part, with the exception that
certain operations are so inefficient on GFS that they generate
significant I/
On Tue, 2008-08-19 at 12:13 -0300, Sebastien Tandel wrote:
> Hi Timo,
>
> On 14 Aug 2008, at 17:04, Timo Sirainen wrote:
>
> > On Aug 14, 2008, at 2:38 PM, Giorgenes Gelatti wrote:
> >
> >> I've been studying dovecot for replacing my company's current system
> >> and I got a little worried about
Hi Timo,
On 14 Aug 2008, at 17:04, Timo Sirainen wrote:
On Aug 14, 2008, at 2:38 PM, Giorgenes Gelatti wrote:
I've been studying dovecot for replacing my company's current system
and I got a little worried about an aspect of the dovecot's design.
I was surprised that dovecot doesn't use prefo
On 16 Aug 2008, at 01:44, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Aug 15, 2008 at 03:37:53PM -0300, Sebastien Tandel wrote:
[...]
[fork is fast]
OK, it measures the fork instruction. But fork is using a copy-on-
write
mechanism
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Aug 15, 2008 at 03:37:53PM -0300, Sebastien Tandel wrote:
[...]
>> [fork is fast]
> OK, it measures the fork instruction. But fork is using a copy-on-write
> mechanism ... It means that *none* of the parent's memory pages are copied.
> Eac
The master process exec's the mail process (imap or pop3) after fork.
gpg
2008/8/15 Sebastien Tandel <[EMAIL PROTECTED]>:
> Hi,
>
>
>>> It is well known that preforking is a good pratice if you want to
>>> achieve a higher performance.
>>> When I was asked about it I readily answered: "of course
Hi,
It is well known that preforking is a good pratice if you want to
achieve a higher performance.
When I was asked about it I readily answered: "of course it does".
For
my surprise later, i doesn't.
With fork latencies in the range of 500 to 1500 microseconds (on
Pentium
900 MHz-class
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Aug 14, 2008 at 03:38:50PM -0300, Giorgenes Gelatti wrote:
> Hello All,
[...]
> It is well known that preforking is a good pratice if you want to
> achieve a higher performance.
> When I was asked about it I readily answered: "of course it do
On Aug 14, 2008, at 4:25 PM, Giorgenes Gelatti wrote:
2008/8/14 Timo Sirainen <[EMAIL PROTECTED]>:
But there are even some theoretical problems with preforking. For
example
the most secure way to set up your users is to use a different UNIX
UID for
each user. So for preforking that means you
2008/8/14 Timo Sirainen <[EMAIL PROTECTED]>:
> But there are even some theoretical problems with preforking. For example
> the most secure way to set up your users is to use a different UNIX UID for
> each user. So for preforking that means your preforked processes must run as
> root until they rec
On Aug 14, 2008, at 2:38 PM, Giorgenes Gelatti wrote:
I've been studying dovecot for replacing my company's current system
and I got a little worried about an aspect of the dovecot's design.
I was surprised that dovecot doesn't use prefork for its mail
processes, forking a new processes for each
Words by Giorgenes Gelatti [Thu, Aug 14, 2008 at 04:46:04PM -0300]:
> Woa!!
>
> Do you have statistics of access/min for pop3?
>
No, but I 'greped' 2300 logins/minute peak for a given day for *IMAP*.
> Indeed it could be premature since I didn't measure any real
> bottleneck. Just something tha
Woa!!
Do you have statistics of access/min for pop3?
Indeed it could be premature since I didn't measure any real
bottleneck. Just something that got my attention.
[]'s
giorgenes
2008/8/14 Jose Celestino <[EMAIL PROTECTED]>:
> Words by Giorgenes Gelatti [Thu, Aug 14, 2008 at 03:38:50PM -0300]:
Words by Giorgenes Gelatti [Thu, Aug 14, 2008 at 03:38:50PM -0300]:
> Hello All,
>
> I've been studying dovecot for replacing my company's current system
> and I got a little worried about an aspect of the dovecot's design.
> I was surprised that dovecot doesn't use prefork for its mail
> processe
Hello All,
I've been studying dovecot for replacing my company's current system
and I got a little worried about an aspect of the dovecot's design.
I was surprised that dovecot doesn't use prefork for its mail
processes, forking a new processes for each new client connection.
Talking in the #dove
This is is follow up to my previous post about dovecot performance being
slow.
BTW, thanks to all that replied.
For one month we have been trying to figure why suddenly dovecot was slow.
We had two server's running dovecot with the same config and one was fine
while the other wasn't very slow. T
hopefully this
helps out the situation.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Kenny Dail
Sent: Tuesday, May 29, 2007 7:57 PM
To: dovecot@dovecot.org
Subject: Re: [Dovecot] Dovecot] dovecot performance question
> Hi, using the latest dovecot wit
] On
Behalf Of Jason Godsey
Sent: Tuesday, May 29, 2007 10:19 PM
To: dovecot@dovecot.org
Cc: Paul A
Subject: Re: [Dovecot] dovecot performance question
I had this problem when running under vmware (time slippage). I took vmware
out of the loop and all is well.
Also, you should be using ntpd, not
I had this problem when running under vmware (time slippage). I took
vmware out of the loop and all is well.
Also, you should be using ntpd, not cron and ntpdate -b.
Paul A wrote:
Hi, using the latest dovecot with pop3/imap. Using mostly outlook 2003 for
pop3 and squirrel mail imap.
I have
> Hi, using the latest dovecot with pop3/imap. Using mostly outlook 2003 for
> pop3 and squirrel mail imap.
>
> I have a lot of users reporting back that imap is very slow. We average
> about 300 imap and another 700 pop session at any given time.
reporting that imap is slow or that squirrelmail
Hi, using the latest dovecot with pop3/imap. Using mostly outlook 2003 for
pop3 and squirrel mail imap.
I have a lot of users reporting back that imap is very slow. We average
about 300 imap and another 700 pop session at any given time.
Here's my config:
disable_plaintext_auth: no
login_dir: /
73 matches
Mail list logo
