[ 
https://issues.apache.org/jira/browse/GUACAMOLE-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17123997#comment-17123997
 ] 

Mike Jumper commented on GUACAMOLE-1090:
----------------------------------------

{quote}
... I will execute the script for batch operation ...
{quote}

What are you referring to here?

{quote}
When the target resource plays the video, guacd also consumes a large amount of 
CPU.
{quote}

If you are playing video within the remote session, you can expect that guacd 
will consume CPU processing the content of that video. This is expected. Both 
the OS kernel and guacd will balance resources as needed, and you can expect 
that guacd will consume the resources that are available.

The behavior you describe is only an issue if there is a subjective degradation 
in the quality of other connections (ie: if a particular set of connections 
requires so much processing that other connections degrade in responsiveness 
due to having less processing available), in which case you should allocate 
greater server resources.

> Using the RDP protocol to connect to the target resource for refresh or 
> playback of video guacd will consume a large amount of CPU
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GUACAMOLE-1090
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1090
>             Project: Guacamole
>          Issue Type: Bug
>          Components: guacamole-server
>    Affects Versions: 0.9.14, 1.0.0, 1.1.0
>         Environment: centos7.5
>            Reporter: LY
>            Priority: Major
>
> When I use the RDP protocol of guacd to connect the target machine, I will 
> execute the script for batch operation, and check that the CPU occupied by 
> guacd will always be 100%. When the target resource plays the video, guacd 
> also consumes a large amount of CPU. Is there any way to solve this problem?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to