V7 Bug? "Throughput" graph only visible on latest job run

[cparker4486]

Hello,

While testing V7 I noticed that only the latest run of a job displays anything in the Throughput graph. All other job runs are blank.

[Vitaliy S.]

Chris,

Actually it is by design, as saving and displaying graphical information for historical job runs was causing too much load (in terms of CPU/Memory and Storage resources) on the SQL Server. While graphs are empty, you still have information on the throughput in the tables above the chart.

Thanks!

[cparker4486]

Hi Vitaliy,

Allow me to use the Smilies to the right to convey my feelings.

If that is the case what is the purpose of the graph at all except for eye-candy? Serious question. The way I expected to use it was to find trends, visually, from one job to the other. If I can't do that... what should I be doing with that information? How is it useful to me? If it causes such a load on the server my vote is for removing completely.

Actually, I find the explanation to be questionable. It's hard to believe that this couldn't be done efficiently. Beyond that though, why not alert the user that the data is being retrieved? "Loading..."

I'm just so blown away by this. It's very strange.

[Vitaliy S.]

Chris, I completely agree with you and I just passed the information I've been given by our dev team. Let me raise this question one more time internally. Thanks for the feedback.

[cparker4486]

Thank you. I appreciate that very much.

[Vitaliy S.]

BTW, if you want to check job trends and you have Veeam ONE v7 (part of Veeam Backup Management Suite) installed, then I would recommend looking at Job Historical Information report that can help you quickly spot all the changes in the job behavior.

[cparker4486]

That's good to know. I haven't been utilizing ONE like I should so I'm definitely going to take a look at that. And you bring up a good point. If Veeam ONE does reporting on jobs and the graph in B&R is inefficient, let ONE do its job and let B&R do its job.

[Vitaliy S.]

And again, I agree you with you on this point too. Once you have enough time to look at our predefined reports list, please let me know what you would like to see improved there, this feedback would be highly appreciated. Thanks!

[tsightler]

I don't think it was just about performance, but also about the amount of data stored in the DB over time. Most customers run using the included SQL Express version which is fairly limited on CPU, Memory, and DB size. Also, I don't believe the purpose of the graph was to provide any historical performance as Veeam ONE has you covered in that regard, rather I think the graph was included as a way to visualize real-time performance and to provide a view that's similar in style to modern Windows copy dialog. I still find it quite useful for the purpose of visualizing what's happening in real-time as various servers are processed from different disk and various VMs have different amounts.

[cparker4486]

... data stored in the DB over time.

SQL Server 2008 R2 Express has a maximum db size of 10GB. If they have calculated that they can't reasonably store more than one job-run's worth of graph data per job they are doing something seriously wrong. It's a bit silly, no?

On top of that data loses its significance over time so pruning historical statistical data and replacing it with a graphic that says "Graph data pruned" is, IMHO, far and away better than the current implementation.

I still find it quite useful for the purpose of visualizing what's happening in real-time ...

This requires that the admin monitors the job as it's running. I don't want to monitor the jobs in real-time and I suspect this is true for many other people. I think it is much more useful to be able to peruse the job-runs over time to see patterns.

[Gostev]

All, sorry for late response, as I am on the road. It was a conscious decision we've made to only store the graph for the latest job run, I remember these discussion from a few months ago very well. In the first v7 builds, we were storing this graph for all sessions, and this was causing performance and database growth issues. This is not changing, the only thing we can consider is storing 3-5 latest sessions instead of just the latest, if this helps... but I would prefer to avoid because it adds complexity around pruning older sessions, and not much real value for the product.

[Gostev]

If they have calculated that they can't reasonably store more than one job-run's worth of graph data per job they are doing something seriously wrong. It's a bit silly, no?

I think you don't realize the scale some of our customers are using Veeam at. Hundreds of near-CDP jobs will generate thousands of log sessions daily... but I can say QC did not even have to go this crazy to see significant database growth after introducing this feature. A few hours of performance data at 20 sec intervals per job made a huge change to database space consumption...

[cparker4486]

Hi Gostev,

I think you don't realize the scale some of our customers are using Veeam at.

Possibly. But I think the overriding points I'm trying to make are that the current implementation leaves much to be desired (IMO) and that there is a way to do this efficiently and at scale. Recording, analyzing, and displaying statistical data can be done efficiently. Using my browser, I can load 10s of thousands of records, from a CSV file, with multiple datapoints each, and display them on the screen in a line graph, with D3.js, in fewer than two seconds. Similarly, vCenter Server records a huge amount of statistical data all day long and can display that as well without too much trouble.

Certainly there is a way for Veeam to find a solution that makes sense for their product and their customers. The current implementation, IMO, appears to be half-baked.

Don't get me wrong. This is only meant as constructive criticism. I am a huge fan of Veeam and have been a customer for a long time.

[cffit]

I'm experimenting with network throttling with our backup copy jobs to the cloud. I'd like to be able to look at the Backup Copy job history and see what kind of data transfer speeds I was getting during the Backup Copy Job, much like I can do with regular backup to disk jobs. I don't see that shown in the details of the Backup Copy Job though. Is there anywhere this is noted?

[cffit]

I see that only my full backup jobs show the throughput when I look at history whereas incremental and backup copy jobs do not. Is this by design?

[foggy]

I can see processing rate in statistics for successful incremental backup job runs as well as disks reading speed for backup copy jobs (if select particular VM to the left).

[cffit]

Correct, but I'm interested in the throughput so I can see if my throttling is working or not as I backup to cloud.

[foggy]

Sorry for the delay, actually only the last session should show throughput graph and this is by design, please review above for some reasoning behind this. Do you see different behavior?