What's the best way to support more extenders/clients?

[wayner]

There has been a bit of discussion here on how to support more clients since with the current max of a 1GB JVM many folks, including me, start to run into issues with 3-4 clients simultaneously connected to the server, especially if they use lots of Fanart in their UI - I use Gemstone with Movie walls with around 800 movies in total, plus I use banners for series.

There have been at least two proposals on how to fix this:

1. Move to 64 bit Java
2. Have each extender/client run in its own JVM.

Anyone have opinions on which way to go, and can I kindly request that one of our developers work on this?

[Fuzzy]

Originally Posted by wayner

There has been a bit of discussion here on how to support more clients since with the current max of a 1GB JVM many folks, including me, start to run into issues with 3-4 clients simultaneously connected to the server, especially if they use lots of Fanart in their UI - I use Gemstone with Movie walls with around 800 movies in total, plus I use banners for series.

There have been at least two proposals on how to fix this:

1. Move to 64 bit Java
2. Have each extender/client run in its own JVM.

Anyone have opinions on which way to go, and can I kindly request that one of our developers work on this?

I like things to be modular, so I like the idea of each UI instance in it's own JVM. Not as memory efficient, but RAM is cheap. Jeff alluded to this being what is done on Google Fiber, but I haven't looked into the v9 code to see if that is the case there already.

[Narflex]

Originally Posted by Fuzzy

I like things to be modular, so I like the idea of each UI instance in it's own JVM. Not as memory efficient, but RAM is cheap. Jeff alluded to this being what is done on Google Fiber, but I haven't looked into the v9 code to see if that is the case there already.

I would strongly encourage the 64bit route instead. Otherwise you have to launch each individual JVM for all the clients to connect to and it replicates the entire DB in each of their instances which wastes lots of memory.

I'm quite sure it's trivial to use it in 64 bit mode on Linux...I didn't do anything to force compilation to 32 bit, and I've compiled it on Linux on a 64 bit machine many times. So that build by default should be 64 bit....Windows OTOH is another story...I don't have a 64 bit windows machine (and you'd need to exclude the prebuilt 32 bit libraries it uses for things like the USBUIRT, etc....which shouldn't be that big of an issue).

Of course there may be bugs hidden in the native code for 64 bit mode that I'm not aware of...but hopefully we didn't do anything to preclude that (and if we did, it's likely easy to fix).

[scoful]

Originally Posted by Narflex

I don't have a 64 bit windows machine (and you'd need to exclude the prebuilt 32 bit libraries it uses for things like the USBUIRT, etc....which shouldn't be that big of an issue).

I'd send you Windows computer with Win10x64 if you want (or 7 or 8.1). I've literally paid so little for upgrades to SageTV over the years due to your excessive reasonableness upgrade pricing (not to mention the generosity of going open source) and it's been THE most used software in my household since v2, and since I really can't contribute to coding it's the least I can do.

[Narflex]

Originally Posted by scoful

I'd send you Windows computer with Win10x64 if you want (or 7 or 8.1). I've literally paid so little for upgrades to SageTV over the years due to your excessive reasonableness upgrade pricing (not to mention the generosity of going open source) and it's been THE most used software in my household since v2, and since I really can't contribute to coding it's the least I can do.

No thank you. I'll leave that to somebody else.