search

adamtool / webinterface

The web interface for the tool Adam (AdamMC and AdamSYNT) providing an intuitive, visual definition of Petri nets with transits and Petri games, and an interactive interface to the algorithms of AdamMC and AdamSYNT. Contains the repos (as submodules): libs, framework, logics, modelchecking, examples, synthesizer, high-level, webinterface-backend.
http://adam.informatik.uni-oldenburg.de:4567/
GNU General Public License v3.0
5 stars 2 forks source link

Chromium nearly uses all of the processor load #32

Closed mgieseking closed 4 years ago

mgieseking commented 4 years ago

The current version needs nearly all of my processor's load when I mouse over a node in the synthesis approach.

mgieseking commented 4 years ago

Maybe this has s.th. to do with this error on the server:

OnWebSocketError.  Error stack trace: 
org.eclipse.jetty.websocket.api.CloseException: java.util.concurrent.TimeoutException: Idle timeout expired: 300000/300000 ms
    at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onReadTimeout(AbstractWebSocketConnection.java:492)
    at org.eclipse.jetty.io.AbstractConnection.onFillInterestedFailed(AbstractConnection.java:170)
    at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillInterestedFailed(AbstractWebSocketConnection.java:465)
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.failed(AbstractConnection.java:311)
    at org.eclipse.jetty.io.FillInterest.onFail(FillInterest.java:138)
    at org.eclipse.jetty.io.AbstractEndPoint.onIdleExpired(AbstractEndPoint.java:406)
    at org.eclipse.jetty.io.IdleTimeout.checkIdleTimeout(IdleTimeout.java:166)
    at org.eclipse.jetty.io.IdleTimeout$1.run(IdleTimeout.java:50)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.util.concurrent.TimeoutException: Idle timeout expired: 300000/300000 ms
    ... 8 more
OnWebSocketError.  Error cause stack trace: 
java.util.concurrent.TimeoutException: Idle timeout expired: 300000/300000 ms
    at org.eclipse.jetty.io.IdleTimeout.checkIdleTimeout(IdleTimeout.java:166)
    at org.eclipse.jetty.io.IdleTimeout$1.run(IdleTimeout.java:50)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:834)
Websocket closed.  Statuscode: 1001, reason: java.util.concurrent.TimeoutException: Idle timeout expired: 300000/300000 ms
annyanich commented 4 years ago

It shouldn't have anything to do with the server. That is a timeout message indicating that the websocket was closed by inactivity after a 300 second timeout. (I put it in a new issue #33.)

The high CPU load on the client can be attributed to

  1. updating/painting the SVG and 2) updating the physics simulation, I think.

In 1d8891c7b3f05420de00daeb9907642ffd0c947d I have made a change so that the physics simulation will no longer run in situations where no nodes are being dragged around. I have observed that that reduced the CPU load somewhat in the case of having a completely frozen net and just mousing over the same node over and over.

I will have a look into profiling and optimizing it more, because I still see very high CPU usage when quickly mousing over a net (probably attributable to point 1) or when dragging a node in an otherwise fully frozen net (which might involve both 1 and 2)).

mgieseking commented 4 years ago

OK, I just was a little bit surprised since I wasn't aware of the problem before and the problem is not existing in Firefox. For sure, we decided to not have the physics simulation running the whole time because of the CPU load, but I think the consumption in Firefox is OK, but Chromium really took it all. It is possible that this problem existed the whole time for Chromium and I just wasn't aware of it because I normally only use Chromium for testing.

annyanich commented 4 years ago

I think this was also an issue in FF, but FF was a bit faster than Chrome, and your machine is fast enough that you did not notice.

I think you will find the performance to be much better now :)