|
Try as I might, I cant get a sample application to behave badly so no point in talking to MSE.
Something that could be totally unrelated is that I tried to investigate some Internal MGGUI Errors that were sometimes getting written to mgerror.log by these functions (for no observable reason).
Stepping through with the debugger, or adding debug code made them go away. So I added a Verify Warning with no message immediately after my BrowserSetContent and not only did the errors go away, but it seems (without looking very hard)
that the bloating has also gone. Maybe it’s a couple of milliseconds for XPA/Windows/Virus Checking to sync its processes, maybe it’s a total red herring.
Highly circumstantial, and I will probably be back on this in the future, but I am happy to park it for now.
toggle quoted message
Show quoted text
From: main@magicu-l.groups.io <main@magicu-l.groups.io>
On Behalf Of Todd Baremore via groups.io
Sent: 01 November 2022 15:41
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Browser Control Memory/CPU Hog
Steven,
A customer just installed a new Windows 2019 server and the XPA 4.8.1 browser control works perfectly on it. This server uses Trend Micro Security Agent. The problem server uses Vipre. Both are 2019 Standard. Not saying that Vipre is the problem, but I
need to investigate further.
Todd
On 10/25/2022 11:35 AM, Steven Burrows wrote:
Thanks,
Trying to set up a simple example for MSE, but so far it works fine. Must be missing some complexity (originally it’s simple program with a browser control using blobs and BrowserSetContent - called 4 times from program that has a conditional
initial form - called from a frame, all with placement and conditional sizing so I think I am pushing XPA a little).
Will add my grrr to the Server 2019 issue at the same time if I manage to reproduce it suitably.
Steven,
I was not aware of the memory issue, but will look in to it. Unfortunately I am aware of the Windows 2019/CefSharp problem and have no solution to offer you. From what I have read, it appears that CefSharp needs to be version 101 or higher. I tried using
a newer version, but could not get it to work with XPA4.8.1
Todd
On 10/25/2022 4:58 AM, Steven Burrows wrote:
XPA 4.8.1
We recently added a Frame/Subform that has Browser Controls to display relevant KPIs.
Every time the Subform is refreshed each Browser Control causes a new CefSharp.BrowserSubprocess.exe to be spawned in Task Manager. Each is 10MB – 100MB, and these processes are not ended/disposed of until the Parent Task is exited so it
bloats rather quickly.
Except when it doesn’t of course – About 25% of the time, XPA reuses the existing processes as I would expect. Same machine, not exiting Studio, just run the Application sometimes works, sometimes bloats.
Also, on Windows Server 2019, each of the CefSharp processes that should be “live” are using a lot of CPU (2% of a 40 Core machine) even when not in Focus. On a Windows 10 machine, there is no detectable CPU usage.
Any tips to try before I raise it with MSE ?
Steven Burrows
|
|
|
Steven,
A customer just installed a new Windows 2019 server and the XPA
4.8.1 browser control works perfectly on it. This server uses
Trend Micro Security Agent. The problem server uses Vipre. Both
are 2019 Standard. Not saying that Vipre is the problem, but I need
to investigate further.
Todd
On 10/25/2022 11:35 AM, Steven Burrows
wrote:
Thanks,
Trying to set up a simple example for MSE,
but so far it works fine. Must be missing some complexity
(originally it’s simple program with a browser control using
blobs and BrowserSetContent - called 4 times from program that
has a conditional initial form - called from a frame, all with
placement and conditional sizing so I think I am pushing XPA a
little).
Will add my grrr to the Server 2019 issue
at the same time if I manage to reproduce it suitably.
Steven,
I was not aware of the memory issue, but will look in to
it. Unfortunately I am aware of the Windows 2019/CefSharp
problem and have no solution to offer you. From what I have
read, it appears that CefSharp needs to be version 101 or
higher. I tried using a newer version, but could not get it
to work with XPA4.8.1
Todd
On 10/25/2022 4:58 AM, Steven Burrows
wrote:
XPA 4.8.1
We recently added a Frame/Subform that
has Browser Controls to display relevant KPIs.
Every time the Subform is refreshed
each Browser Control causes a new
CefSharp.BrowserSubprocess.exe to be spawned in Task
Manager. Each is 10MB – 100MB, and these processes are not
ended/disposed of until the Parent Task is exited so it
bloats rather quickly.
Except when it doesn’t of course –
About 25% of the time, XPA reuses the existing processes
as I would expect. Same machine, not exiting Studio, just
run the Application sometimes works, sometimes bloats.
Also, on Windows Server 2019, each of
the CefSharp processes that should be “live” are using a
lot of CPU (2% of a 40 Core machine) even when not in
Focus. On a Windows 10 machine, there is no detectable CPU
usage.
Any tips to try before I raise it with
MSE ?
Steven
Burrows
|
|
|
If you're willing to have a bit of an adventure, you could have a look at getting Microsoft WebView2 working in preference to CEFSharp.
I did poke around a bit awhile ago but it hasn't come up for me to do more on this for now.
If I were leading MSE R&D I would swap out CEFSharp for WebView2 in the product but, well, you know, I'm not.
"Our job is improving the quality of life, not just delaying death".
toggle quoted message
Show quoted text
From: main@magicu-l.groups.io <main@magicu-l.groups.io> on behalf of Steven Burrows <steven.burrows@...>
Sent: Tuesday, October 25, 2022 8:35 AM
To: main@magicu-l.groups.io <main@magicu-l.groups.io>
Subject: Re: [magicu-l] Browser Control Memory/CPU Hog
Thanks,
Trying to set up a simple example for MSE, but so far it works fine. Must be missing some complexity (originally it’s simple program with a browser control using blobs and BrowserSetContent - called 4 times from program that has a conditional
initial form - called from a frame, all with placement and conditional sizing so I think I am pushing XPA a little).
Will add my grrr to the Server 2019 issue at the same time if I manage to reproduce it suitably.
From: main@magicu-l.groups.io <main@magicu-l.groups.io>
On Behalf Of Todd Baremore via groups.io
Sent: 25 October 2022 13:44
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Browser Control Memory/CPU Hog
Steven,
I was not aware of the memory issue, but will look in to it. Unfortunately I am aware of the Windows 2019/CefSharp problem and have no solution to offer you. From what I have read, it appears that CefSharp needs to be version 101 or higher. I tried using
a newer version, but could not get it to work with XPA4.8.1
Todd
On 10/25/2022 4:58 AM, Steven Burrows wrote:
XPA 4.8.1
We recently added a Frame/Subform that has Browser Controls to display relevant KPIs.
Every time the Subform is refreshed each Browser Control causes a new CefSharp.BrowserSubprocess.exe to be spawned in Task Manager. Each is 10MB – 100MB, and these processes are not ended/disposed of until the Parent Task is exited so
it bloats rather quickly.
Except when it doesn’t of course – About 25% of the time, XPA reuses the existing processes as I would expect. Same machine, not exiting Studio, just run the Application sometimes works, sometimes bloats.
Also, on Windows Server 2019, each of the CefSharp processes that should be “live” are using a lot of CPU (2% of a 40 Core machine) even when not in Focus. On a Windows 10 machine, there is no detectable CPU usage.
Any tips to try before I raise it with MSE ?
Steven Burrows
|
|
|
Thanks,
Trying to set up a simple example for MSE, but so far it works fine. Must be missing some complexity (originally it’s simple program with a browser control using blobs and BrowserSetContent - called 4 times from program that has a conditional
initial form - called from a frame, all with placement and conditional sizing so I think I am pushing XPA a little).
Will add my grrr to the Server 2019 issue at the same time if I manage to reproduce it suitably.
toggle quoted message
Show quoted text
From: main@magicu-l.groups.io <main@magicu-l.groups.io>
On Behalf Of Todd Baremore via groups.io
Sent: 25 October 2022 13:44
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] Browser Control Memory/CPU Hog
Steven,
I was not aware of the memory issue, but will look in to it. Unfortunately I am aware of the Windows 2019/CefSharp problem and have no solution to offer you. From what I have read, it appears that CefSharp needs to be version 101 or higher. I tried using
a newer version, but could not get it to work with XPA4.8.1
Todd
On 10/25/2022 4:58 AM, Steven Burrows wrote:
XPA 4.8.1
We recently added a Frame/Subform that has Browser Controls to display relevant KPIs.
Every time the Subform is refreshed each Browser Control causes a new CefSharp.BrowserSubprocess.exe to be spawned in Task Manager. Each is 10MB – 100MB, and these processes are not ended/disposed of until the Parent Task is exited so it
bloats rather quickly.
Except when it doesn’t of course – About 25% of the time, XPA reuses the existing processes as I would expect. Same machine, not exiting Studio, just run the Application sometimes works, sometimes bloats.
Also, on Windows Server 2019, each of the CefSharp processes that should be “live” are using a lot of CPU (2% of a 40 Core machine) even when not in Focus. On a Windows 10 machine, there is no detectable CPU usage.
Any tips to try before I raise it with MSE ?
Steven Burrows
|
|
|
Steven,
I was not aware of the memory issue, but will look in to it.
Unfortunately I am aware of the Windows 2019/CefSharp problem and
have no solution to offer you. From what I have read, it appears
that CefSharp needs to be version 101 or higher. I tried using a
newer version, but could not get it to work with XPA4.8.1
Todd
On 10/25/2022 4:58 AM, Steven Burrows
wrote:
XPA 4.8.1
We recently added a Frame/Subform that has
Browser Controls to display relevant KPIs.
Every time the Subform is refreshed each
Browser Control causes a new CefSharp.BrowserSubprocess.exe to
be spawned in Task Manager. Each is 10MB – 100MB, and these
processes are not ended/disposed of until the Parent Task is
exited so it bloats rather quickly.
Except when it doesn’t of course – About
25% of the time, XPA reuses the existing processes as I would
expect. Same machine, not exiting Studio, just run the
Application sometimes works, sometimes bloats.
Also, on Windows Server 2019, each of the
CefSharp processes that should be “live” are using a lot of
CPU (2% of a 40 Core machine) even when not in Focus. On a
Windows 10 machine, there is no detectable CPU usage.
Any tips to try before I raise it with MSE
?
Steven
Burrows
|
|
|
XPA 4.8.1
We recently added a Frame/Subform that has Browser Controls to display relevant KPIs.
Every time the Subform is refreshed each Browser Control causes a new CefSharp.BrowserSubprocess.exe to be spawned in Task Manager. Each is 10MB – 100MB, and these processes are not ended/disposed of until the Parent Task is exited so it
bloats rather quickly.
Except when it doesn’t of course – About 25% of the time, XPA reuses the existing processes as I would expect. Same machine, not exiting Studio, just run the Application sometimes works, sometimes bloats.
Also, on Windows Server 2019, each of the CefSharp processes that should be “live” are using a lot of CPU (2% of a 40 Core machine) even when not in Focus. On a Windows 10 machine, there is no detectable CPU usage.
Any tips to try before I raise it with MSE ?
Steven Burrows
|
|
|
