Jump to content

Parallel HTTP requests with LabVIEWHTTPClient.lvlib GET.vi


Recommended Posts

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

 

Link to comment
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.

Link to comment

@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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.