[imapproxy] configuration advice [was :ImapProxy session issue ]

[G G Papazoglou]

> I'll reply further to this original post when I get time.  My advice for now
> is to test it well.   This is because I've had trouble in the that past with
> imapproxy, which seems to have been fixed when I upgraded my imap server.
> So I know first hand that it will work or not based on how buggy your imap
> server is.  Also, of the 3 or 4 performance reports to the imapproxy list,
> the worst performing one was on solaris.  Since you are using solaris, you
> will want to be a bit weary.  I think the other one might have been solaris
> 8 though, so it may or may not apply.

I am using UW IMAP. Yet I don't have the time now to upgrade to
another IMAP (eg. Cyrus), although I haven't had any problems with my
current server for almost one year now.

> There is an expect script you can use, which will tell you if imapproxy
> itself is working at all for you.  It is in the imapproxy cvs now.  See
> the PERFORMANCE file (in docs/ I think) for info.  This will tell you 
> what kind of imap performance increase you will see.  But it won't tell
> you how that will affect the performance of IMP per se.

I think I'll have a look. Thanks.

> I'm inbetween those.  About 2K users total, during peak maybe 30-50 
> concurrent users in IMP.  Many others using other imap/pop3 users.  Lots of
> sendmail activity.  Very busy, but most don't use IMP while at work (more
> used when out of the office than in the office).

The case for me as well.

> It isn't necessary, but it could well improve performance.  There are certain
> operations that require IMP to hammer the server, and while that is not going
> on most of the time, when it does it will help.  Also, if you have users like
> me who read a lot of small mails really fast (about a message every 4-5
> seconds sometimes) then it will really speed up their experience.  So even
> with the smallest site, it will help in certain situations.  Maybe your overall
> experience isn't impacted, but the speed of some special case situations will
> be improved, and that is a good thing.

> There are two uses for imapproxy.  The first is to take some of the load off
> your imap server.  If your imap server is overloaded then this is why you want
> it.  In your small setup, this probably isn't an issue.  The second reason is
> to speed up IMP.  This is where you will see the benefit.

In fact that's the reason I installed imapproxy in the first place. It
is obvious I don't have performance issues in my IMAP server, yet
since most of IMP's users use it via dial-up, performance is crucial.

So, now I have it working as follows:

keepalive       60
client_timeout  60
server_timeout  120
stats_frequency 60
max_reuse       30

I am not sure what it does, actually. I can't see any difference. I
can't even be sure of any decrease of performance. Btw, the
docs/PERFORMANCE mentions that using imapproxy IMP runs 2 times
slower...

I think I'll turn it off.

Regards,
Greg