Parallel HTTP requests with LabVIEWHTTPClient.lvlib GET.vi

[Wim]

Hi Guys,

 

It has been a while but I'm back :-)

 

I'm having some 'problems' with http requests ....

 

Project summary:

LabVIEW 2010 Application that reads sensor logs from a database.

 

The application gets its data via http requests: --> architecture of the project --> data must be accessible via web-service 

 

Example: http://localhost:8085/sensorservice/sensor/test/temperature..... (and some paramaters about the amount of data to return.) is entered in the LabVIEWHTTPClient.lvlib:GET.vi and I receive my data in the body and header controls.

 

So far so good.

 

Every data request takes about 0.3 s Not bad .... but .... all sensors that are read in the application are handled sequentially in a FOR loop.  So 60 sensors *0.3s == 18s update rate.

Not fast enough for my customer.

 

The LabVIEWHTTPClient.lvlib:GET.vi is reentrant and it allocates an instance for each clone.  

 

So i quickly made an active object for each sensor and call the LabVIEWHTTPClient.lvlib:GET.vi by ref with x08 as option when i open the vi ref.

 

It returns the data BUT ... requests are still sequential and not parallel :-(  

 

LabVIEWHTTPClient.lvlib:GET.vi blockdiagram is protected with a password, but I assume it still blocks because of a dll call.

 

Did anyone make an application with parallel http requests ?

 

Thx.

 

Wim

 

[ShaunR]

Something similar was discussed here: Get HTTP vi not Reentrant? (surprised you are not using websockets for this)

[Rolf Kalbermatter]

Hi Guys,

 

It has been a while but I'm back :-)

 

I'm having some 'problems' with http requests ....

 

Project summary:

LabVIEW 2010 Application that reads sensor logs from a database.

 

The application gets its data via http requests: --> architecture of the project --> data must be accessible via web-service 

 

Example: http://localhost:8085/sensorservice/sensor/test/temperature..... (and some paramaters about the amount of data to return.) is entered in the LabVIEWHTTPClient.lvlib:GET.vi and I receive my data in the body and header controls.

 

So far so good.

 

Every data request takes about 0.3 s Not bad .... but .... all sensors that are read in the application are handled sequentially in a FOR loop.  So 60 sensors *0.3s == 18s update rate.

Not fast enough for my customer.

 

The LabVIEWHTTPClient.lvlib:GET.vi is reentrant and it allocates an instance for each clone.  

 

So i quickly made an active object for each sensor and call the LabVIEWHTTPClient.lvlib:GET.vi by ref with x08 as option when i open the vi ref.

 

It returns the data BUT ... requests are still sequential and not parallel :-(  

 

LabVIEWHTTPClient.lvlib:GET.vi blockdiagram is protected with a password, but I assume it still blocks because of a dll call.

 

Did anyone make an application with parallel http requests ?

 

Thx.

 

Wim

 

Why would you call the HTTP Get.vi by reference and not put it simply inside your Active Object? You don't happen to use the same VI ref in each Active Object because this will basically serialize the calls since a VI ref is exactly one instance of the VI with one data space. Instead simply dropping the VI into your Active Object VI will propely allocate a new instance of the reentrant VI for every time you drop it on a diagram somewhere.

 

Since the VI is set to be reentrant I would assume strongly that whatever Call Library Node is inside will be set to execute in any thread too. There might be some arbitration underneath in the DLL that could serialize the calls somewhat but I would first try to get rid of any VI server invocation before speculating to deep about non-reentrancy of otherwise properly reentrant configured VIs.

 

Or go with websockets like Shaun suggested.

[Wim]

@ShaunR: thanks for the links. I'll check them.

 

@rolfk: I tried just putting the VI in the active object but without succes.  So my next test was calling it by ref.

 

But, i read in the links from ShaunR that the speed can depend on calling the get vi with or without handle.

 

So, i quickly did a test: Now I open a handle in the create of my active object and use this with the GET vi in place in the active object.

 

And ....  speed was better.  I went from 20s to 13s.

 

I also did an 'architecture' update (sometime duplicate info was read) and now i have an update rate of 6s.

 

Now I have to convince my customer to 'redesign' the application so I can make a final version of the active objects.

 

thanks guys.