[SOGo] BTS activities for Saturday, March 02 2019

2019-03-02 Thread SOGo reporter
Title: BTS activities for Saturday, March 02 2019





  
BTS Activities

  Home page: http://www.sogo.nu/bugs
  Project: SOGo
  For the period covering: Saturday, March 02 2019

  
  
idlast updatestatus (resolution)categorysummary
	
	
	  
	
4695
	2019-03-02 18:05:39
	updated (open)
	Web Calendar
	Days in upcoming events view are out of order
	
	  
	
  
  


-- users@sogo.nuhttps://inverse.ca/sogo/lists

Re: [SOGo] Performance tuning

2019-03-02 Thread Lorenz Pressler
> Try using http://www.imapproxy.org/ in between SOGo and your IMAP 
server.


I would have thought this would just have the same effect as 
"NGImap4DisableIMAP4Pooling = NO;"
however response times are worse (>1.5s). When I additionally enable 
pooling then the response time is about the same as using no proxy again 
(500-1000ms).


regards,

--
Lorenz Pressler

--
users@sogo.nu
https://inverse.ca/sogo/lists


Re: [SOGo] Performance tuning

2019-03-02 Thread Ludovic Marcotte

On 2019-03-01 4:12 a.m., Lorenz Pressler (lor...@pressler.pro) wrote:

Viewing a mail in the SOGo webmail interface however takes > 1s which 
makes it bothersome to use (from the click on the message in the 
message list to viewing the mail content in the message pane). I 
enabled a few debug options in the conf and the log is showing me eg:


> Mar 01 11:47:42 sogod [49882]: |SOGo| starting method 'POST' on uri 
'/SOGo/so/lor...@mydomain.tld/Mail/unseenCount'
> Mar 01 11:47:43 sogod [49882]: |SOGo| request took 1.591988 seconds 
to execute 

Try using http://www.imapproxy.org/ in between SOGo and your IMAP server.

--
Ludovic Marcotte
lmarco...@inverse.ca  ::  +1.514.755.3630  ::  https://inverse.ca
Inverse inc. :: Leaders behind SOGo (https://sogo.nu), PacketFence 
(https://packetfence.org) and Fingerbank (https://fingerbank.org)

--
users@sogo.nu
https://inverse.ca/sogo/lists


Re: [SOGo] Performance tuning

2019-03-02 Thread Lorenz Pressler

Hi Odhiamb,

I tried setting it to 128M and I tried moving it to a unix socket. Both 
resulted in nothing noticable but I did not really expect anything on 
the cache side since everything else but accessing mail is reasonably fast.


regards,

--
Lorenz Pressler



--
users@sogo.nu
https://inverse.ca/sogo/lists


Re: [SOGo] userPasswordAlgorithm

2019-03-02 Thread Ludovic Marcotte

On 2019-03-02 11:31 a.m., Odhiambo Washington (odhia...@gmail.com) wrote:


Is this something that can be avoided?

By setting prependPasswordScheme = NO.

--
Ludovic Marcotte
lmarco...@inverse.ca  ::  +1.514.755.3630  ::  https://inverse.ca
Inverse inc. :: Leaders behind SOGo (https://sogo.nu), PacketFence 
(https://packetfence.org) and Fingerbank (https://fingerbank.org)

--
users@sogo.nu
https://inverse.ca/sogo/lists


[SOGo] userPasswordAlgorithm

2019-03-02 Thread Odhiambo Washington
I am able to change passwords, right, but I see that the password
encryption scheme prepended to the encrypted password in the DB.
Is this something that can be avoided?

And why is digest-md5 not among the supported encryption algorithms?
I don't see it listed in the Docu under "Possible values" while reference
is made to https://wiki.dovecot.org/Authentication/PasswordSchemes, which
has it listed.


Thanks

-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Performance tuning

2019-03-02 Thread Markus Winkler

Hi Lorenz,

On 01.03.19 22:42, Lorenz Pressler (lor...@pressler.pro) wrote:

yes, this made indeed a difference; it's about ~20-30% faster.
response time taken from the debug log is now ~500-1200ms.


as expected, I would say. ;-) Thank you for testing and your feedback.


I am not sure why though or I am misunderstanding what this is doing.


If this parameter is not set, the default setting is effective, which means 
IMAP pooling is disabled. In this case SOGo has to log in _and_ especially 
out for every access to/from the IMAP server and so permanently establishes 
new sessions to Dovecot. A typical log extract would look like this (while 
clicking in the web interface):


--- snip ---
2019-03-02 10:49:32 imap-login: Info: Login: user=, 
method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=15163, secured, 
session=

2019-03-02 10:49:32 imap(f...@example.com): Info: Logged out in=222 out=1607

2019-03-02 10:49:37 imap-login: Info: Login: user=, 
method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=15167, secured, 
session=<3WMIcRmDIsl/AAAB>

2019-03-02 10:49:37 imap(f...@example.com): Info: Logged out in=331 out=2116

2019-03-02 10:49:39 imap-login: Info: Login: user=, 
method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=15169, secured, 
session=

2019-03-02 10:49:39 imap(f...@example.com): Info: Logged out in=331 out=2116

2019-03-02 10:49:42 imap-login: Info: Login: user=, 
method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=15171, secured, 
session=<3ctbcRmDLMl/AAAB>

2019-03-02 10:49:43 imap(f...@example.com): Info: Logged out in=307 out=4075
--- snip ---

In contrast to that, if you set 'NGImap4DisableIMAP4Pooling = NO;' then the 
pooling is activated, SOGo keeps the current connection open and so _no_ 
new logins are necessary every time you access a folder or e-mail. In the 
Dovecot log you'll only see one login and that's it. The down side is, that 
there will be more simultaneous open connections to Dovecot.


I'm also new to SOGo and hope that my understanding of this mechanism is 
correct. I don't know exactly if and when timeouts on SOGo and Dovecot 
regarding the IMAP connection are taking effect (at least there is some 
information in the RFC's and the Dovecot Wiki). According to the Dovecot 
log it seems that SOGo logs out after about 5 minutes of inactivity in the 
web frontend (but I didn't check this exactly).


Well, this test was mainly for isolation and confirmation of one possible 
reason for the performance bottleneck - the slow IMAP login/access. And 
with changing this parameter we can indeed mitigate this problem. But for 
me it's unclear, why the login resp. access to Dovecot takes so long 
compared to the same procedure using Thunderbird or OpenSSL/fetching as 
IMAP clients. Perhaps there are some SOGo experts which have any idea how 
to narrow down this further and have tuning tips?


By way of comparison: in the sogo.log of my server (Debian, 2 GB RAM with 
software components like on your system and with 
'NGImap4DisableIMAP4Pooling = NO;') I can see IMAP access times on an 
average of 0,1 s, if an initial IMAP login was necessary before then this 
takes approx. 0,4 s.


And BTW: it doesn't suprise me that your access to address book and 
calendar is working well, as they are stored exclusively in the MariaDB and 
this access is something completely different.


Best regards,
Markus
--
users@sogo.nu
https://inverse.ca/sogo/lists