Delay on first request

Ziti Overlay
1

Hello everyone, I have a simple setup with a host and client, where the host has a GET route which just returns some text.
The client uses the python SDK with monkeypatching, here’s the code :

“import os
import openziti
import requests

ztx = openziti.load("ziti/identity.json")
if ztx is None:
raise RuntimeError("Identity load failed")

openziti.monkeypatch()

resp = requests.get("http://winpreprod.zpix:2612/pix/out/v1.0/GetToken")
print(resp.status_code)
print(resp.text)
”

The code works as expected and returns the intended response, but there is roughly a 10-second delay before the first response. When making multiple requests in a row (with a for loop before requests.get), the same ~10-second delay occurs only for the first request, while all subsequent responses arrive instantly. It seems to me that the delay is caused by the initial setup of the Ziti tunnel, but I don’t have any idea on why it’s the case.

I also can’t manage to have the logs printed with the Python SDK, even when setting ZITI_LOG_LEVEL=debug, so I don’t have more infos.

Any help would be greatly appreciated

2

Do you get a better result with the context manager approach shown in this requests example?

1 Like
3

correct environment variable is ZITI_LOG, and it is numeric -- 1 -> ERROR, 2 -> WARN, etc

1 Like
4

The same delay applies as well with the example code.
With ZITI_LOG=4, I can see what’s causing the delay. There’s 2 instances :
”(91054)[ 0.001] DEBUG ziti-sdk:ziti_ctrl.c:1106 ctrl_paging_req() ctrl[https://zpix.vigitronic.eu:8440/edge/client/v1\] starting paging request GET[/external-jwt-signers]
(91054)[ 5.064] DEBUG ziti-sdk:ziti_ctrl.c:502 ctrl_body_cb() ctrl[https://zpix.vigitronic.eu:8440/edge/client/v1\] completed GET[/version] in 5.057 s”

“(91054)[ 5.302] DEBUG ziti-sdk:connect.c:527 process_connect() conn[0.0/6MuOgQPn/Connecting](2612) requesting 'Dial' session for service[2612]
(91054)[ 10.201] DEBUG ziti-sdk:channel.c:966 on_tls_connect() ch[0] connected alpn[ziti-edge]”

From what I see the delay seems to come from the controller (or the network but I doubt it), but I don’t really know what could cause that

5

this is what (probably) causing the delay. it looks like a slow DNS resolution

What OS are you running on?

can you try hitting controller URL with cURL?
Can you run wireshark or tcpdump to see packet flow for that connection? make sure to capture DNS requests as well

2 Likes
6

Hey, thanks for your answer.
It was actually due to a DNS problem as you figured.
After a bit of digging, I found that the first DNS address in /etc/resolv.conf was faulty. I’m pretty sure it’s an old, deleted DNS server used when I had the tunneler installed instead of the SDK. It works nicely after removing it

Sorry the issue wasn’t really related to Ziti but thanks for your help and solution!

2 Likes
7

no worries, and thanks for the update

1 Like