Is this already supported ?

I'm actually doing some test and I don't think the server is zipping the zinc format answer.

gzip enable is selected in the Niagara Web Service

Hi Christian,

Do you know for sure that the Niagara gzip option should apply to custom servlets? I'll have to look into it further myself.

How big is the Zinc content you are trying to send over the wire? Is it worth the effort to gzip it or are you adding more overhead?

Sending raw Zinc has always been pretty snappy even across the Internet in my experience but if more people think it's worthwhile then we should consider if it's something important to add.

Cheers, Richard

Richard,

No I don't know if it could apply to servlet.

My use case is the following : I'm doing numerical analysis using Python. Yesterday I run my script to retrieve, from a Jace, 1 week of data for 10 controllers (4 points each)... took me about 20-30 minutes to gather everything.

That's pretty long delay. In fact I restarted the script a few time before opening Wireshark to see what was going on.

Each response was made of multiple TCP Segments in the Wireshark log so I thought that if the data was zipped, I would have gained a lot of speed. Zinc is text only and text fits really well in a zip file.

Note that this slow speed is due to the Jace hardware, from my understanding, because if I run those scripts connected to a computer running nhaystack (Supervisor) it's really fast.

Christian,

I did something very similar using Python + pandas + postgresql.

Found that running the script each night for "yesterdays" data to work very well. The script would retrieve yesterdays data (in json format) and append to a CSV file. At the end of the week you will have a CSV file with one week of data that can be read into a pandas dataframe. Pandas can cleanse the data and dump to postrgres.

My work in this area has stopped because I upgraded my jace to Niagara 4. I haven't seen nhaystack for n4 yet..

I have an ipython notebook I could share with examples if you're interested.

Best, Brandon

Yes, I'm interested in seeing what you did.

But the basic fact is, for one time validation (let say you didn't run a script every day for a particular client) it should be possible to benefit from compression to accelerate data transmission.

I'm using haystack in a context of specific numerical analysis for example :

I have a client where I suspect the balancing to be bad. I want to validate airflow using electrical heating in the duct and delta T around it to see if it seems to fit measured airflow.

I can't count on the fact that I "thought" to fill a database for each of my clients in case I would want to check something.

By the way, have you tried the latest pyhaystack module ? https://github.com/ChristianTremblay/pyhaystack/tree/Mixins_issue6

I see. I don't think my scripts will show you anything you don't already know. My use case was very similar, in that I had a client that suspected the reheat coils "should" have been two-pass coils rather than single-pass coils because they were seeing massive energy usage. The building had the capacity to heat the space (boiler sized correctly) but the space would not reach a comfortable temperature unless the building was in an occupied state pretty much all night.

I ended up writing the python scripts to pull "yesterdays" data each night. I ran the scripts via a cron job each night when I thought the traffic would be minimal. On a larger scale (eg multiple clients) I would probably not use cron jobs for this task. I think Python's Celery package is ideally suited as a task runner for multiple clients. For this particular instance Cron handles everything just fine. I never had to remember to do anything.