A more efficient proxy...

Originally Posted by nilly

@dwdude, Thanks for the input. Two of my characters died likely due to the delay induced by the proxy and the 100% cpu usage. I'm think about rewriting the proxy so that one thread handles both inputs from the client and the server and adds them to a queue and then another thread handling both outputs to the client and server. A third thread (the mediator) would be used to look at the input queues and make changes and what not and pass them to the output queues. I also want to prioritize the processing of packets so that packets like escape get sent out immediately without touching the mediating thread. Then set the priority of the input/output threads to high and maybe lessen the priority of the mediating thread. Just some ideas I had that might help some. It is unfortunate that cpu usage has such an impact on the proxy though. :/

It isn't kidding when it says 100% usage! It's not so much that the proxy needs a lot of cpu, it's that Flash does. With 9 clients open, drawing the screen, that's some serious cpu usage. It sounds weird that a silly Flash window can require THAT much from your cpu that it's essentially locked up, but it's true. It's a pretty big reason why I stopped trying to multibox. I had multiple different types of steamrolling setups in place, but Flash is too hard on my processor to allow me to do it. Opening up 4 TF2 windows is nothing. Opening up 16 TF2 windows is nothing. Opening 4+ RotMG windows... You notice something.

A little trick I learned is that if you reduce the max fps the .swf file plays at it dramatically reduces the cpu usage. If you tried running 4+ clients all set to run at 60fps your processor will cry. On the other hand if you set it to something lower, like 30fps, or like in my video 20fps (I usually use 30fps but lowered it to 20fps because of the recording impact) you'll notice the clients taking far less cpu cycles.

How much cpu % is the jvm is using. Even though your CPU is at 100%, if the jvm is running at 5% the problem isn't with the proxy. If it is taking up a significant chunk, then I would recommend profiling the code to see which methods eat up the most execution time.
Also, I would rewrite everything to use the queuer since that's threadsafe, so it becomes much easier to debug, but I suppose that's optional if you got it working. Also, send every packet in the queue before sleeping. Refer to this:sleep - How to suspend a java thread for a small period of time, like 100 nanoseconds? - Stack Overflow
Lastly, your queue loop should basically be instantaneous, since I assume you're adding your custom location packet to all the slave server-to-client queues. If it's not, then there's a problem somewhere.

Besides that, cool project.

Thanks for the input @marinepower. I didn't pay attention to how much cpu jvm was taking up but I'll be sure to in the future. I did notice that the program was taking up an aweful lot of memory for god knows what. On the order of 350mb which I found shocking. Also upon connection of a client (perhaps at other times too) I'd get, on occation, OutOfMemory errors (jvm memory usage spiked to 1000mb+ in an instant before tumbling back down after the error) so something is wrong even if it has nothing to do with the lag I spoke of.

After readin this i feel intelligent

A more efficient proxy...

Post a Reply

Similar Threads

Tags for this Thread