Play Framework WebSocket Endpoint not Responding


(Joe San) #1

I have been working on a project that can simulate the operation of a PowerPlant!

Here is the link to the project:

So this basically represents a digital twin for the PowerPlant per se. I just wanted to see how good my application works. I wrote set of scripts to create 100000 PowerPlants in the database. When I start my plant-simulator play application, I read the database table and for each PowerPlant in the table, I create an Akka Actor instance and a corresponding StateMachine object. I mutate the StateMachine based on the messages that my Akka Actor receives.

So far so good. I now wrote another script that can send a burst of dispatch commands to each of these PowerPlant’s. A dispatch command is a command with which I can ramp up the PowerPlant, i.e., I can make the PowerPlant to deliver power by sending a dispatch command to it.

Now when the PowerPlant Actor receives the dispatch command, it starts to ramp that PowerPlant up in a sequence of steps. Once the PowerPlant is ramped up to the desired Power level as indicated in the dispatch command, it emits an event into a Monix observable which is then piped to a WebSocket endpoint.

So what I did was, while I’m sending the burst of dispatch commands, I opened the chrome browser’s Websocket client and was trying to see the events that were happening. To my surprise, I could not see all the events being pushed. Is it because of the fact that the WebSocket chrome client could not handle this? My Chrome WebSocket client sort of freezed and I could neither close it nor open an another one! Is this because of my application using too many threads? or am I blocking threads? I’m puzzled!

Could anyone please guide me? I would like to validate my implementation if it is fit for scale!

Can anyone please point me to some ideas as to how I could do some performance benchmarking?

Thanks and Regards,

(Rich Dougherty) #2

How many events are you expecting to flow over the WebSocket and how fast are they coming? An easier way to validate might be to use logging or collect summary statistics on the server-side instead events over a socket.