Improve performance of script that detects the primary address

[apertome]

The function that returns the primary address information is slow and is used all over the place. Can this be optimized? Ideally for 3.5.1. Don't know what the scope of this is.

[apertome]

Adding some context, each page on the UI depends on this feature and it takes a long time to load, every time.

Assigning Andy since he has some knowledge of this area of the code. Don't know if he's really the best person to do this or not.

[igarny]

Copying here a suggestion from Valentin, with some additional extension on the proposal:

I'm not sure if this is the issue mentioned on the meeting today, but perhaps dev and src can be parsed from ip output:

-----Original Message----- From: perfsonar-developer-request@internet2.edu [mailto:perfsonar-developer-request@internet2.edu] On Behalf Of Valentin Vidic Sent: Donnerstag, 21. Januar 2016 18:08 To: perfsonar-developer@internet2.edu Subject: [perfSONAR-developer] Default interface and IP address

$ ip route get 8.8.8.8 8.8.8.8 via 161.53.160.1 dev eth0 src 161.53.160.40 cache

$ ip route get 2001:4860:4860::8888 2001:4860:4860::8888 from :: via fe80::161:53:160:1 dev eth0 src 2001:b68:ff:1::40 metric 0 cache hoplimit 64

-----Original Message----- From: Garnizov, Ivan (RRZE) Sent: Donnerstag, 21. Januar 2016 18:21 To: Garnizov, Ivan (RRZE); Valentin Vidic; perfsonar-developer@internet2.edu Subject: RE: [perfSONAR-developer] Default interface and IP address

If you allow me to rephrase my emails:

Our first option should be to look for _primaryinterface in the ls_configuration_daemon.conf at <service_template local_web_service>

If not then apply the suggestion from Valentin to chose the the correct primary interface using the preference for a custom sLs server (again ls_configuration_daemon.conf). if this parameter is also empty just take the address of the LS servers in the bootstrap file to apply same test. . A possible pitfall here would be if some smart guy has configured different interfaces to have the default for IPv4 and IPv6. In this case I would suggest to define this as a configuration error and have an internal check with configuration_daemon, for instance, that triggers an event in logs and/or GUI.

Best regards, Ivan

[apertome]

I believe this is the code that does the primary address detection: https://github.com/perfsonar/perl-shared/blob/master/lib/perfSONAR_PS/Utils/Host.pm#L243

@mfeit-internet2 or @arlake228 may want to take a look? Or someone else?

[mfeit-internet2]

Looks like in this case, "primary interface" means "first interface whose address reverse-resolves to a hostname and isn't on one of the private blocks." Not a great assumption to make, but I guess it would work in some cases. I could also see it not being deterministic if multiple interfaces meet those criteria and enumerate in a different order different times.

The bottleneck is probably the DNS lookups; I didn't look at the function it calls, but I could see that taking awhile if done serially on a host with a lot of IPs. I can look at that function if you want and see if it does its queries in parallel or can be made to work that way.

[apertome]

I don't think it's the DNS lookups, I'm running it on nodes with 2 interfaces so it seems unlikely that that would be the issue.

[arlake228]

@apertome: is this still relevant?

[apertome]

@arlake228 as far as I know, yes, it is still relevant. I don't think it's causing any major problems, but it does cause delays in the GUI when loading any info relating to interfaces.