V10 - Slower B&R console after startup

[alexander sh]

There's some UI and SQL performance improvements planned for Cumulative patch 2 in addition to the hotfix being discussed in this thread, so definitely install that when it's out.

@FrancWest - regarding stale information shown in the UI - have you tried refreshing UI with F5 rather than reopening?

[FrancWest]

Hi, no, wasn't aware of the F5 option. I switched to another screen and then back, but that didn't solve it.

[mweissen13]

Even with Version 9.5, I had to occasionally press F5 since the UI wasn't always up-to-date after running for extended periods of time. There is certainly still room for improvement in this area, but it's only a minor inconvenience.

[cfizz34]

Love the F5 trick, thanks for posting it!!!!

[ChrisGundry]

I can see there are other topics about this, but Veeam response seems to be this is solved in v10 P2, so I am posting a new topic.

Is anyone else seeing the v10 console being very slow and hanging on various operations? This never really happened in v9.5 and it is very noticable now in v10. We have not changed our B&R server config, HW spec etc, so don't see why this is now happening.

Times this has happened:
Opening the console (not for the first time) - The console opens, but the view is blank. It sits like this for several minutes. Doesn't happen every time you open, but sometimes.
Changing view from Backup to BackupCopy - View is empty and will eventually load after several minutes.
Expanding Backups>Backup>Backup job x - When expanding to see the VMs and # of restore points within it, it hung for several minutes.

Case #04235236.

As I said, this was never an issue in v9.5, and I noticed it the first time I opened the v10 console. I checked the forum and saw there was something about building a cache, so I thought OK, this is fine. But the next time I opened it, I got the same issue. Where is this new 'cache' located? Is it a client side thing or something in the DB or what? We are currently working in VDI, so it might be that something is 'cached' somewhere that is non-persistent maybe.

Thanks

[Gostev]

I explained the reason why it is happening in that other topic you already saw... this is an architectural change in v10. I'm merging this thread there, since we don't want to have duplicate discussions on the same problem.

The cache is located in the backup server RAM. However, it is not being rebuild or updated constantly unless there are consoles using it, so at some point it will expire after the last console is closed. Opening the console will trigger cache repopulation, which can take time.

Thanks!

[ChrisGundry]

I am not sure how this explains the issue I am having.

You said that this is a change to improve performance of the GUI (and not have it hang) and reduce load on the SQL database.

I am not seeing the 'green dots' when waiting for the backups to expand, or when the screen is just blank and there are no backup jobs listed.

I get that you have made a change to try and improve things. But as a customer I am saying this console is performing the worst I have ever seen the Veeam console. It seems that every time I try and do something the console either shows a blank list, or shows the green dots. If that is because it is building the cache, then I would question why the cache is not being retained/updated on the server side in the background. I have the console open all day every day and use most views daily. So the cache of the list of jobs etc. should be retained. At the worst case, even if the cache is updated every time someone goes into the backup job list (which seems like a bad idea), it never took 2-3 minutes to load the backup list before, it loaded almost instantly. FYI, we have maybe 30 jobs total. We do have a decent number of restore points via GFS and storage snapshots. But when it hung I was only expanding two jobs, which had maybe 50 VMs total between them and 7 restore points per VM. Again, this previously took a few seconds max, this hung for 2-3 minutes.

When talking to support, they are saying there are no known issues and that it must be because of x, y or z. You are saying this is related to the intended architectural change in v10.

Whichever way I look at this v10 console is a big step down for us as a customer.

[foggy]

Hi Chris, I encourage you to continue working with support on this. Even if there are currently no known issues around console performance, this doesn't mean there couldn't be some new one, or specific to your environment, which they will help to identify. You can also ask them to try tweaking the timeouts mentioned by Anton above and feel free to escalate the case if nothing helps.

[PariPari]

Hey,

we have the same issue in our SP Environment. Is the mentioned hotfix suitable for v10 P2? If yes, we will start a request from Veeam Support.

[Gostev]

The above-mentioned hotifix is included in v10 P2. Thanks!

[PariPari]

Okay, then we need to open a ticket
The console is still slow when opened or when viewing jobs or backups. It's pretty tedious.

[lowlander]

Hi,

we are using VBR for agent backups (windows). We have configured VBR to use an external SQL database, however we sometime have a slow / unresponive console interface on the VBR server.

Anyone experienced this behaviour ?

I will submit a case for this issue.

thanks !

[Natalia Lupacheva]

Hi @lowlander,

Moved your post to the existing thread.
Could you please clarify the exact version you use?
Also, please share your support ticket id once it's opened.

Thanks!

[ChrisGundry]

I just wanted to update this that we never got a reasonable answer from support and due to workload and other Veeam issues we gave up and lived with it. Support's main suggestion was that our SQL server was to blame. The SQL server was running on the B&R server itself, which it always had done. We have made no changes to that, but updated to v11a a few weeks ago and our performance is back to normal once again! We don't have the stupid hanging or freezing anymore, it just works like it did before in v9 and older. So I maintain that whatever was done in v10 to improve things caused us issues. I don't know what happened between v10 and v11a that fixed this, but something did because we have not done anything else!

[Gostev]

Chris, thank you so much for remembering about this thread and coming back to post the final solution. It was indeed a long path and multiple iterations of understanding and fixing various bottlenecks.