Request for bumping up the maximum of listeners per sim

[Ramesh Ramloll]

Hello Illan / Oren,
I have an application which requires a number of listeners : O(n) where n is the number of objects rezzed. Right now the 1000 limitation of the total number of listeners is not enough for my purpose. On a local opensim install, I tried to pump up this value to 2000 and I could not identify any negative impact on the rest of the opensim region. I will be very grateful if you could increase the maximum number of allowable listeners per region to 2000. Let me know if this will not be possible and why.
Thanks
Ramesh

[Ilan Tochner]

Hi Ramesh,

The maximums that are set as default are intended to protect against having a high number of resource intensive scripts. Your scripts may not require a lot of resources but other people's do and we can't set maximums that disregard the fact that multiple OpenSim instances may share the same server.

At your request we've already increased maximums from the recommended OpenSim defaults. Doubling them again may cause other people's worlds to encounter problems and force us to have to handle OpenSim bugs and/or inefficiencies that aren't encountered at lower settings levels.

I'm sorry because I know this isn't the answer you want to hear, but we are focused on developing business critical features at this time, such as the upcoming Kitely Market, and don't want to divert our resources to debugging and/or optimizing OpenSim.

[Ramesh Ramloll]

Hello Illan,
Just to clarify, the maximum number of listeners per script, was increased to 500 on my request. The default per script is 64. So thanks for this.
What I have done is that I decreased my number of listeners per script to only 2 which is well below the original 64.
However, the sim wide application grows depending on user interactions and as more content is dynamically injected in. So the total number of listeners (as distinct from listener per script) is what is limiting here.
Is there another technical reason other than 'others don't need it?' I was hoping for kitely to be a product deployment platform on my end, not a prototype development platform, and then I'll have to deploy my own servers to meet my needs, that is another option of course ... may be it might indeed be a better option for those who need to customize opensim .ini files.
Ramesh

[Graham Mills]

Could you use osMessageObject as well as or instead of listeners? Mind you, I've no idea what the limits might be in that case.

[Ramesh Ramloll]

Thanks Graham, I will investigate. The limits on osMessage not documented unfortunately. Interesting to note though that threat level is low.
I think a mixed approach (osMessage and listener together) will make my code messier. I think that in the future, hopefully kitely users will have some control on the initialization aspects relevant to their instance. Right now, one solution fits all may limit diversity of applications.

[Ilan Tochner]

Hi Ramesh,

Please reread my previous reply. I never said that this isn't something other people may be interested in, I stated that changing the default OpenSim configuration values can have repercussions that we don't want to have to deal with at this time. Some OpenSim configuration values may be arbitrary or inherited from Second Life limitations but others are there to prevent load and lag issues that can result form the system being used with parameters it wasn't optimized to handle.

I haven't researched how listeners are implemented in OpenSim but if they are handled in a synchronous loop that blocks other scripts from running until it completes then doubling the number of listeners in combination with having increased the maximum listeners per script to 500 can potentially create extreme lag - maybe not with your particular script combination but with scripts that other people will run in some other world that will take advantage of those increased maximums.

We want to have your business and would hate for you to leave but we need to configure our servers in a way that can ensure that everyone will maintain good performance. If you wish to hand optimize OpenSim configuration values and experiment to make sure that those values work under your usage scenarios on your dedicated hardware then you may indeed wish to get your own dedicated server(s). Just make sure you don't use a shared hosting environment because what may work when your OpenSim instance is running on its own dedicated server may not work as well (or at all) when other OpenSim instances are sharing that server. Also, take into consideration that Kitely has various proprietary systems, such as our cloud-based asset and inventory systems, that greatly reduce server load compared to regular OpenSim, especially when your user concurrency increases. So, if you go the dedicated server route make sure to do a lot of stress testing with your increased configuration values.

[Ramesh Ramloll]

Hi Illan,
You could reduce the number of listeners per script from the current 500 back to its default 64 for peace of mind regarding the scenarios you fear can happen. As I said I reduced the number of listeners per script (to only 2) so that it falls well below the default 64.
I think if slowdown or lag is an issue resulting from the total number of permissible listeners per *region*, it might be easier for a region owner to mediate access either through scripts or price ... both technically or socially.
I did some experiment on my end, and I do not experience any slow down when I doubled the total number of listeners per region personally. I asked on opensim list. When it was done, it appears that no impact was observed.
I do understand your cautious approach.
There are no system that fit perfectly one's needs ... I will struggle to work around. If the application turns out to be a killer app for my audience, and if they crave more interactivity, then I will have to overcome the constraint.
Ramesh

[Constance Peregrine]

Hi Ramesh,

Let's get to the point where the current OpenSim default limit becomes a problem for your usage scenario then reassess. It's possible that by that time OpenSim's performance will have improved sufficiently for the default value to be raised without our needing to test the implications of doing so.