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 into this
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.
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 reduce traffic
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
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
Quoting Timo Sirainen t...@iki.fi:
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
Quoting Wojciech Puchar woj...@wojtek.tensor.gdynia.pl:
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
Quoting Timo Sirainen t...@iki.fi:
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
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.
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
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.
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'.
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:
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
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, sorted by
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
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
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
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)
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) understanding
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 applications we have
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 running
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:
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 played with
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 install
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.)
roundcube can if
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 there's
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 true for
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 there's
Quoting Timo Sirainen t...@iki.fi:
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
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
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
Quoting Ed W li...@wildgooses.com:
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.
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)
Not
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 forking
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
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.
There is
still
37 matches
Mail list logo
