[7.950][FEATURE][CLOSED] Throughput count very low

I was going to submit this as a bug earlier during the beta but I think this behavior has carried over from v7. If you download large amounts close to midnight, the executive report doesn't give an accurate count. However the accounting data is not lost and is simply added to the next day. So in your case, I bet your downloaded data would be a lot more than you actually downloaded today.

Interesting that you are not seeing it this morning and unless something has changed it should be in your daily executive report tonight.  The sql backend is great for a lot of things but sometimes you just want all counters to stop and restart at midnight when the daily executive report runs [;)]

Hi Billybob,
you can go back through a number of betas and production where I have raised this question.

The data count I am missing is all from after midnight. When I get home I will add the webadmin reports network usage graphs which shows the distribution.

Regards

Ian M

Update.

Now 1800 local time. Total traffic for the day according the ASG is nearly 2.7gb. Total traffic according to my ISP is about 8.3gb.
So it is not an interpretation of bits and bytes or 1000=1024.

I have attached the graphs for the internal and external interfaces.

Then there is the question of what packet type carried the data?
The interface stats show port 80 and 8080 amongst others of carrying about 400mb, where as the web stats show 2.6gb.

Yes, I could open up lots of logfiles and analyse the info, but why when the ASG provides a summary.

Ian M

The counting takes place when a "flow" has been completed. So if you start a download on monday afternoon, and the download is not completed on monday, it will not appear on any report for monday. To take this even further, if you are streaming data and the stream lasts for more than a week, you might not even see it in a weekly report.

The problem that we're facing here is that these "flows" are something that the kernel provides for us, and it does it when the flow ends (ie. the connection is closed). If we wanted to make these connections visible for the reporting, we would have to either interrupt the connections once a day or we would have to put a part of the reporting into the kernel and keep track of those long-lived open connections in kernel space (which we will not do for obvious performance and stability reasons.

I know that this behavior is an itch for everyone, but please, if you really want this part of the ASG to be improved, head over to feature.astaro.com and file something like "more granular reporting of long-lived traffic flows". [SIZE="1"](Don't get me wrong, i would like to see this working in a more natural way, more in line with my expectations too. But as i explained above, this is not a V8 bug, this is a big feature that needs lots of planning)[/SIZE]

Hi Kbr,
so what you are saying is that if someone opens a connection at 2350, but doesn't start downloading until 0015, the download completes at 0130 and a fresh one starts at 0150 and finishes at 0550 that is counted as one contiguous download?

In theory both situations would be new connections because of a different url to get the data from.

You answer makes more sense than the previous ones I have been offered.

Ian M

... so what you are saying is that ... that is counted as one contiguous download?

no, but i think we have to take simpler example.

Think of the following situation: You have two PCs at home and use both to SSH into your ASG. The one PC is an always-on Desktop, the other one is your Laptop.
From the Desktop you log in  into your ASG on monday afternoon, start the 'top' utility and leave it running.
Now you got to the kitchen, grab the laptop, log in into the ASG and take a look at the logfiles. After that you disconnect and power off the laptop. (The Desktop is still running).

On the next day, you will see the SSH session related data in the report, but it will be only the data from the laptop session, because on your Desktop, the connection is still open. And, it is the same connection as yesterday. It hasn't been terminated yet. Because it hasn't been terminated, the reporting does not see it (yet).

Surfing the web is a different problem here, because from the web browser itself you cannot see how many connections are beeing made during a surfing session. Even a simple visit of the google image search page might connect you to multiple servers (each server is at least one separate connection), but - depending on the configuration of the webserver and website you are visiting - there's a chance that all the images and the javascript for the main site is going through the same, single tcp-connection, which is then counted as one "flow".
Amongst the browser developers there's been an agreement to open a maximum of two tcp connections to each server and then re-use these connections for follow-up webrequests. This feature is called "http 1.1 pipelineing". So you can request hundreds of images through one tcp connection, which is then counted as one "flow" on the ASG.

Hi kbr,
great explanation. You should make it a sticky in the main forum.

Thank you

Ian M

So if I restart the http proxy, the download should showup?

great explanation. You should make it a sticky in the main forum.

Thanks, but... Hmm, maybe i should find a native english speaking guy from our US team to fix the spelling, grammar and weak phrases first...

So if I restart the http proxy, the download should showup?

Probably yes, but it would also corrupt your dowload, because you are breaking the file in half.

Hi kbr,
I should have said if I restart the http proxy after the download has finished, the download will show up in report?

Regards

Ian M