0

I'm working on a huge application and we got some serious troubles regarding the performance of the software. I don't want to bother you with too many details, so in short:

  • in one JVM runs the GUI (JavaFX)
  • in another JVM runs the logic
  • the two JVMs communicate with eachother over socket (for fast transmissions) and http

The logic-jvm is doing periodically (1/10s) some data analysis and creates a structure containing some numbers and images (rgb,640*480). The gui needs to visualize this data in the same speed and displaying the images. Currently the gui requests 10 times a second this data from the logic jvm over http, whereas the data itself is sent over a socket connection. This circumstance came from the idea to be able to attach multiple gui to one logic. But as the time showed, we will not be doing this. Furthermore, the performance is really bad, as soon as the data (mainly due to more images) gets bigger (250MB). It seems that the bottleneck is, where we put the image data into the bytebuffer and sending it. As stated before, we probably won't ever have multiple gui - so why not using only one jvm.

What speaks for the current solution:

  • We can set the priority of the applications in windows. the logic really needs to run smoothly and is given a high priority. The gui application should also run smoothly but nobody cares if it would skip a frame or two.

Further the gui has some views, in which properties (for simplicity SimpleObjectProperty) in the logic should be altered. I.e. a JavaFx TextField should be bound bidirectional to a SimpleString property in the logic part. So updating the string inside the logic will alter the textfield and vice-versa.

gui

TextField tf = new TextField();
tf.textProperty().bindBidirectional(observableOfLogic);  

I hope you get some feeling for the situation.

Now I finally like to state my question:

What is the best design for such a problem?

Thank you very much in advance.

1

I can't provide for you the "best" approach for what you are trying to accomplish, but I can do my best to help you make some good system level decisions and improve your application.

1) Reducing complexity is helpful in increasing performance. You seem to have come to the conclusion that you don't need a remote GUI. Great, keep it in the same VM. Please be mindful of concurrency in the resulting application, however. Look at the resources here for good practices on concurrency and JavaFX.

2) Think of your problem as a Video Problem. In the video world, it's normal to deal with rapidly providing a visual stream from multiple images. There are lots of solutions here, and some may fit your needs. One to look into is FFMPEG. FFMPEG is a cross platform solution to create, convert, and/or stream video and audio. Moving your issue into the video space also has the added benefit of readily providing solutions for remote streaming should you ever decide that you need remote or multiple guis. An example of image to video conversion for FFMPEG is here. Information about a Java wrapper for FFMPEG can be found here.

3) If utilizing video won't work for your situation and memory pressure is causing the bottleneck, only keep 2-3 images around at any one time. For instance, the image currently being rendered to the GUI, the latest image completed by the logic, and the image currently being generated by the logic. Multithreaded interactions are an issue here. Since the logic threads have the priority ensure they never have to wait for a lock in order to processes. Ensure that whatever feeds the GUI takes the performance hit when it becomes necessary to wait for an image to complete. Finally, attempt to use buffers rather than constantly creating new objets every time. This will avoid having the garbage collector running to dispose of thousands of images. Look here to see information about performantly writing images to the canvas.

4) I don't see a tremendous performance hit from the bidrectional text field property when compared to the monster amounts of data your generating on the image side. Just be mindful of concurrency and the effects of lock and other interactive mechanisms. See #1.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.