Kopano Webapp loading the first you enter

craem

Hi, good moorning. I have a Kopano in a Debian 10 with mysql 5.7:

WebApp:
6.0.0.66-1+2030.1
Kopano Core:
11.0.2
Z-Push:
2.6.4+0-0

2 x vcpu, 8 gb ram and 100 gb disc (raid 1)

The mysql config (innodd) is the next:

symbolic-links=0

sql_mode=NO_ENGINE_SUBSTITUTION

bind-address = 0.0.0.0
skip-name-resolve

MyISAM

key-buffer-size = 32M

SAFETY

max-allowed-packet = 16M

CACHES AND LIMITS

tmp-table-size = 32M
max-heap-table-size = 32M
query-cache-type = 0
query-cache-size = 0
max-connections = 500
thread-cache-size = 50
open-files-limit = 65535
table-definition-cache = 4096
table-open-cache = 4096

INNODB

innodb-flush-method = O_DIRECT
innodb-log-files-in-group = 2
innodb-log-file-size = 1024M
innodb-flush-log-at-trx-commit = 1
innodb-file-per-table = 1
innodb-buffer-pool-size = 4G

the first time the customer enters, it takes about two minutes to get ready to send emails and navigate in webapp:

file:///home/angel/Escritorio/Captura%20de%20pantalla%20-2022-03-27%2010-36-45.png

The size of Mysql is 5gb (aprox) and I think is a little database for kopano.

Any ideas to solve this issue ?

Thanks.

Ángel Elena

dw2412

@craem
Thanks for a lot of informations but at least I don’t get a clue from this… Sorry. Just from the vcpu and ram it might have its source but this would not only mean at login. Have it running on my friends PCs with 2 VCPUs, too. Not very quick, but this no one expects. They want to have some groupware and don’t wanted to do big investments but have no problems to wait sometimes a bit more…

So maybe my questions help to direct you into right direction:

You have Z-Push installed. So you have devices that login same way that you do in WebApp. In case if you do a sync with Z-Push at one device - how long does it take? My idea is that it might be related to user plugin used for Kopano. Are you using LDAP, DB or Files plugin?

Does it happen in every browser? Btw, which one is in use for the WebApp?

Are you accessing the server at some hosting provider? How many other VMs running on server? Is there eccessive over provisioning on the hardware node?

For the WebApp, have you enabled OIDC_* defines? If so, are they commented out or are these defines just there as they come from the packages? It could happen because of updates that they’re not there at all and according to my experience it has the result that if they are not there login in Firefox not really works at first attempt. After a reload of the WebAppp everything works as expected for the current session.

How many shared mailboxes are being opened in the profile you use for login to WebApp?

Andreas

craem

@dw2412 Hi, thanks for the interest in the problem. Today I have identified the problem and it is the Files plugin… when I configure the nextcloud account in files and the users loggin the first time, the problem is reproduced and it takes about two minutes to be available.

Yes, I have z-push, openLdap backend and my kopano server is behind a haproxy. All users loggin with firefox (linux).

I’m going to investigate why it takes two minutes to be available.

thanks

dw2412

@craem Since I have Files Plugin installed myself - although I rarely use it myself - I decided to give it a try and have a look what happens in combination with my Nextcloud 23.0.x. Yes - does not work for me, too. But I don’t experience long login duration like you explain.

Seems that the Files Plugin needs somehow an update to fix this. Will have a look if I find out something myself, too.

Little Update: After some time - I set up the account this time with type WebDav - I found following in debug.txt:

[17-Apr-2022 10:44:39] ERROR - array (
  'msg' => 'mapi_getprops() expects parameter 1 to be resource, string given',
  'file' => '/usr/share/kopano-webapp/server/includes/core/class.properties.php:147',
)
[17-Apr-2022 10:44:39]  - '
@ class.properties.php:147 - mapi_getprops(...)
@ class.properties.php:121 - Properties->getStoreMappingSignature(...)
@ class.module.php:65 - Properties->setStore(...)
@ class.listmodule.php:74 - Module->__construct(...)
@ class.fileslistmodule.php:65 - ListModule->__construct(...)
@ class.dispatcher.php:43 - FilesListModule->__construct(...)
@ class.jsonrequest.php:50 - Dispatcher->loadModule(...)
@ kopano.php:151 - JSONRequest->execute(...)
'
[17-Apr-2022 10:44:39] ERROR - array (
  'msg' => 'Undefined index: f5e9d132f9f0333c6559b2118997b1c3!Wichtiges',
  'file' => '/usr/share/kopano-webapp/plugins/files/php/Files/Core/class.accountstore.php:203',
)
[17-Apr-2022 10:44:39]  - '
@ class.accountstore.php:203 - kopano_error_handler(...)
@ class.filesbrowsermodule.php:200 - Files\\Core\\AccountStore->getAccount(...)
@ class.filesbrowsermodule.php:132 - FilesBrowserModule->loadFiles(...)
@ class.jsonrequest.php:57 - FilesBrowserModule->execute()
@ kopano.php:151 - JSONRequest->execute(...)
'

Creating account as Type “Owncloud” results in settings a green status and same status after cache being rebuild. Cache in /var/lib/kopano-webapp/plugin-files was before creating new account. This cache get filled with information after each profile create.

My files Plugin is from supported repo. Following packages are installed on Ubuntu 20.04.4 LTS:
kopano-webapp-plugin-files 4.0.1.7+450.1
kopano-webapp-plugin-filesbackend-owncloud 4.0.0.0+128.1
kopano-webapp-plugin-filesbackend-smb 4.0.0.0+94.1

All other packages (OS and WebApp) are up to date = on latest state repos offer, too.