CardDAV-Sync communicate with Radicale too slow about radicale

[liZe]

That's strange. Do you have the same delay with a simple browser or wget when you try to access to http://192.168.1.123:5232/ ?

[yuq]

No, seem not. here is the log for a browser to access it, the 3 sec delay is for me to enter username and password.

2013-11-18 15:34:26,363 - INFO: GET request at / received
2013-11-18 15:34:26,365 - DEBUG: Request headers:
{'CONTENT_LENGTH': '',
 'CONTENT_TYPE': 'text/plain',
 'GATEWAY_INTERFACE': 'CGI/1.1',
 'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
 'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
 'HTTP_ACCEPT_LANGUAGE': 'zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3',
 'HTTP_CONNECTION': 'keep-alive',
 'HTTP_HOST': 'localhost:5232',
 'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0',
 'PATH_INFO': '/',
 'QUERY_STRING': '',
 'REMOTE_ADDR': '127.0.0.1',
 'REMOTE_HOST': 'localhost',
 'REQUEST_METHOD': 'GET',
 'SCRIPT_NAME': '',
 'SERVER_NAME': 'yuq-Vostro-270',
 'SERVER_PORT': '5232',
 'SERVER_PROTOCOL': 'HTTP/1.1',
 'SERVER_SOFTWARE': 'WSGIServer/0.1 Python/2.7.3',
 'wsgi.errors': <open file '/dev/null', mode 'w' at 0x9820bd0>,
 'wsgi.file_wrapper': <class wsgiref.util.FileWrapper at 0x9768ddc>,
 'wsgi.input': <socket._fileobject object at 0x988102c>,
 'wsgi.multiprocess': False,
 'wsgi.multithread': True,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'http',
 'wsgi.version': (1, 0)}
2013-11-18 15:34:26,365 - DEBUG: Sanitized path: /
2013-11-18 15:34:26,365 - INFO: Anonymous user refused
2013-11-18 15:34:26,365 - DEBUG: Answer status: 401 Unauthorized
2013-11-18 15:34:29,527 - INFO: GET request at / received
2013-11-18 15:34:29,528 - DEBUG: Request headers:
{'CONTENT_LENGTH': '',
 'CONTENT_TYPE': 'text/plain',
 'GATEWAY_INTERFACE': 'CGI/1.1',
 'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
 'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
 'HTTP_ACCEPT_LANGUAGE': 'zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3',
 'HTTP_AUTHORIZATION': 'Basic YWRtaW46YWRtaW4=',
 'HTTP_CONNECTION': 'keep-alive',
 'HTTP_HOST': 'localhost:5232',
 'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0',
 'PATH_INFO': '/',
 'QUERY_STRING': '',
 'REMOTE_ADDR': '127.0.0.1',
 'REMOTE_HOST': 'localhost',
 'REQUEST_METHOD': 'GET',
 'SCRIPT_NAME': '',
 'SERVER_NAME': 'yuq-Vostro-270',
 'SERVER_PORT': '5232',
 'SERVER_PROTOCOL': 'HTTP/1.1',
 'SERVER_SOFTWARE': 'WSGIServer/0.1 Python/2.7.3',
 'wsgi.errors': <open file '/dev/null', mode 'w' at 0x9820bd0>,
 'wsgi.file_wrapper': <class wsgiref.util.FileWrapper at 0x9768ddc>,
 'wsgi.input': <socket._fileobject object at 0x988102c>,
 'wsgi.multiprocess': False,
 'wsgi.multithread': True,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'http',
 'wsgi.version': (1, 0)}
2013-11-18 15:34:29,528 - DEBUG: Sanitized path: /
2013-11-18 15:34:29,528 - DEBUG: admin has NO read access to collection /
2013-11-18 15:34:29,528 - DEBUG: admin has NO write access to collection /
2013-11-18 15:34:29,528 - DEBUG: Answer status: 403 Forbidden
2013-11-18 15:34:29,757 - INFO: GET request at /favicon.ico received
2013-11-18 15:34:29,758 - DEBUG: Request headers:
{'CONTENT_LENGTH': '',
 'CONTENT_TYPE': 'text/plain',
 'GATEWAY_INTERFACE': 'CGI/1.1',
 'HTTP_ACCEPT': 'image/png,image/*;q=0.8,*/*;q=0.5',
 'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
 'HTTP_ACCEPT_LANGUAGE': 'zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3',
 'HTTP_AUTHORIZATION': 'Basic YWRtaW46YWRtaW4=',
 'HTTP_CONNECTION': 'keep-alive',
 'HTTP_HOST': 'localhost:5232',
 'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0',
 'PATH_INFO': '/favicon.ico',
 'QUERY_STRING': '',
 'REMOTE_ADDR': '127.0.0.1',
 'REMOTE_HOST': 'localhost',
 'REQUEST_METHOD': 'GET',
 'SCRIPT_NAME': '',
 'SERVER_NAME': 'yuq-Vostro-270',
 'SERVER_PORT': '5232',
 'SERVER_PROTOCOL': 'HTTP/1.1',
 'SERVER_SOFTWARE': 'WSGIServer/0.1 Python/2.7.3',
 'wsgi.errors': <open file '/dev/null', mode 'w' at 0x9820bd0>,
 'wsgi.file_wrapper': <class wsgiref.util.FileWrapper at 0x9768ddc>,
 'wsgi.input': <socket._fileobject object at 0x988102c>,
 'wsgi.multiprocess': False,
 'wsgi.multithread': True,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'http',
 'wsgi.version': (1, 0)}
2013-11-18 15:34:29,759 - DEBUG: Sanitized path: /favicon.ico
2013-11-18 15:34:29,759 - DEBUG: admin has NO read access to collection /
2013-11-18 15:34:29,759 - DEBUG: admin has NO write access to collection /
2013-11-18 15:34:29,759 - DEBUG: Answer status: 403 Forbidden
2013-11-18 15:34:29,787 - INFO: GET request at /favicon.ico received
2013-11-18 15:34:29,788 - DEBUG: Request headers:
{'CONTENT_LENGTH': '',
 'CONTENT_TYPE': 'text/plain',
 'GATEWAY_INTERFACE': 'CGI/1.1',
 'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
 'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
 'HTTP_ACCEPT_LANGUAGE': 'zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3',
 'HTTP_AUTHORIZATION': 'Basic YWRtaW46YWRtaW4=',
 'HTTP_CONNECTION': 'keep-alive',
 'HTTP_HOST': 'localhost:5232',
 'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0',
 'PATH_INFO': '/favicon.ico',
 'QUERY_STRING': '',
 'REMOTE_ADDR': '127.0.0.1',
 'REMOTE_HOST': 'localhost',
 'REQUEST_METHOD': 'GET',
 'SCRIPT_NAME': '',
 'SERVER_NAME': 'yuq-Vostro-270',
 'SERVER_PORT': '5232',
 'SERVER_PROTOCOL': 'HTTP/1.1',
 'SERVER_SOFTWARE': 'WSGIServer/0.1 Python/2.7.3',
 'wsgi.errors': <open file '/dev/null', mode 'w' at 0x9820bd0>,
 'wsgi.file_wrapper': <class wsgiref.util.FileWrapper at 0x9768ddc>,
 'wsgi.input': <socket._fileobject object at 0x988102c>,
 'wsgi.multiprocess': False,
 'wsgi.multithread': True,
 'wsgi.run_once': False,
 'wsgi.url_scheme': 'http',
 'wsgi.version': (1, 0)}
2013-11-18 15:34:29,788 - DEBUG: Sanitized path: /favicon.ico
2013-11-18 15:34:29,788 - DEBUG: admin has NO read access to collection /
2013-11-18 15:34:29,788 - DEBUG: admin has NO write access to collection /
2013-11-18 15:34:29,788 - DEBUG: Answer status: 403 Forbidden

[yuq]

It only happens for CardDAV-Sync. I have tested libcarddav, it's OK.

[yuq]

But, from wireshark, it's Radicale who hold the communication process for a while (response for 5 sec delay).
Here is the Wireshark result.

[liZe]

Can you check the CPU to find if Radicale is actually doing something during these 5 seconds?

[yuq]

I have checked the Radicale process CPU usage, almost 0% when the CardDAV-Sync is communicating with Radicale. The total CPU usage is also very low.

[liZe]

OK, so that's probably a problem related to the network. As Radicale is using the default Python HTTP server, and as the problem only happens with CalDAV-Sync, I'm pretty sure that the problem comes from CalDAV-Sync.

If the 5s delay is always the same, there's probably a timeout in the server or in the client. It may be caused by a request with a bad content-length header, or something similar. I've met other network-related problems causing strange delays (IPv6 or DNS resolution for example), but they're related to the computer configuration and are not directly caused by the software.

I close the bug for now, feel free to re-open it if you have any clues about something wrong in Radicale.

[yuq]

Do you think if the HTTP headers (like keep alive) will cause this problem?

[christophdb]

Hi, I had the same issue and tried everything: Firewall, other port, other radicale version...
In the end I only had to change in the /etc/radicale/config the value "DNS_LOOKUP=False".
Please try that.
Best regards
Christoph