#SL Large Groups Won’t Load

It seems there are some long term problems with large groups. Seems a large group is 12,500 members… yeah that’s a large group. Some people have pointed out in JIRA SVC-4968 that some much smaller groups run into similar problems.

One user, Point Luminos, suggests that computer resources are the problem, not the viewer. Point has a rather modest computer, Duo Core2 E7500 with 4gb ram. Point tells us that he/she is editing a 36,000+ member list each day without a problem.

However, users with more computer and smaller groups are running into the problem. That is more as in newer CPU and more ram. So, it probably is not just a computer resource problem.

The comments are arguing about whether it is a resource problem on the client or a bug in the SL system. Since some can edit large lists and some can’t edit some not so large lists it suggests another problem than just a size limit or computer hardware.

Last Triage

Currently the last triage is showing as January 2010. Also, the JIRA item remains unassigned even with its Show Stopper status, which seems unusual.

An obvious problem with this JIRA issue is that it is missing the steps for how to consistently reproduce the problem. This could be the reason the JIRA item remains unassigned. Until someone identifies what triggers the problem, everyone is sort of wondering around lost. The Lindens are busy enough with problems they can reproduce and have a good chance to fix. So, until something changes in this JIRA item’s description it is like to remain a low priority.

The topic apparently came up recently in Oz Linden’s TPV meeting. But, OZ doesn’t post the meeting minutes any more. So, unless someone was there, we have no idea what’s up.


The problem affects club and business owners with large groups. As users we sometimes get spammed when an automated notice sender has a problem with a large group list.

Work Around

Stephan Gaudio provided more details and some steps to minimize the problem. One measure is to turn off display names. That apparently makes the list load faster and with fewer problems.

Another measure is to examine your list for avatars that have not logged in got over a year, or whatever time frame you think is appropriate. Eject those members to reduce the count and improve performance.

Land marks in large groups often fail to work too. I see that in groups I know to have less than 700 members. Using an SLURL rather than an LM seems to always work.


There is no doubt there is a problem. It remains unclear what it is. But, various computers and various size lists work without problem and other similar computers and groups have problems. Until the problem is better defined or more people complain, there is little chance the Lindens’ priority will change.

If you have run into the problem, add your experience to the comments. Also, visit JIRA SVC-4968 and click WATCH.

9 thoughts on “#SL Large Groups Won’t Load

  1. I don’t quite understand what you mean by

    Land marks in large groups often fail to work too. I see that in groups I know to have less than 700 members. Using an SLURL rather than an LM seems to always work

    • LM’s in announcements fail to open or save into inventory, if one waits longer than a couple of hours to open the announcements. However, an SLURL appears as a link in the announcement text and always works.

      I doubt LM’s are group size related. I seem to remember another JIRA for that problem. But, the problem is included in the thread as part of the large group size problem.

      I could have worded that paragraph better.

  2. This problem is not new and I worked around it weeks ago in the Cool VL Viewer. It relates with how degraded some legacy protocols became in SL..

    There are two ways to retrieve avatar names in SL. The legacy method involves UDP messaging with the sim server and returns the legacy name of the avatar (“John Doe” for oldies or “JohnDoe Resident” for newbies) while the new method involves querying a capability (i.e. a web server) via HTTP and returns both the user name (which can be turned into a legacy name) and the display name.

    In its immense wisdom, it looks like LL degraded the UDP name fetches while they are still using them extensively in their own newest viewers (see by yourself and make a: grep ‘gCacheName->get’ viewer-development/indra/newview/). Many third party viewers are still using the old name fetching method for name lists (it looks like LL’s newest viewers is not using it any more for this particular purpose and neither is the Cool VL Viewer) and it is now painfully slow… This is not a problem for short lists (such as for local chat speakers), but it can be for group member lists with thousands of entries.

    One thing is certain, it got nothing to do with the computer performances. However, a badly configured system could also lead to have the HTTP requests failing (and the new method then fails too). One thing to watch for is your network card MTU (Maximum Transfer Unit): some OSes pretend they can discover it automatically (Windows 7, for example), which is wrong (an OS can only guess what is the MTU for packets transmitted by other computers, but it can’t guess the MTU of the ADSL MODEM it is linked to: if the OS uses too large a MTU, the larger packets will simply get lost, which can happen for many reasons anyway and the OS can’t know why they get lost) and most of the time it defaults to 1500 while most ADSL link will only accept 1492 bytes (there’s a 8 bytes overhead due to protocol encapsulation in PPPoA and PPPoE).
    Another problem can be simultaneous HTTP fetches capping: web servers (and the capabilities are web requests, just like are HTTP textures fetches) always cap the simultaneous fetches for a given IP (for example, your IP may be capped at 32 simultaneous connections on a webserver). If the viewer issues too many such HTTP requests at once, this might be an issue. There is a throttling mechanism in the viewer, but it is not a global one (there is a throttling for texture fetches, a throttling for member list fetches, etc, but they are independent from each other), so if you fetch a group member list while rezzing and the requests happen to hit the same web server, you are likely to run into HTTP fetches capping…

    So: if you are using a TPV, it could suffer from the old name fetching protocol degradation. If you are using a TPV using the new name fetching method or the official viewer, you still may suffer from MTU issues, or from HTTP fetches capping.

    • Thank you very much for taking the time to explain the problem.

      I’ll be researching MTU settings and how home-user-routers are dealt with. Also HTTP capping.

  3. Thank you for writing about this Nalates. Maybe the Lindens now consider looking into this. But reproducing the steps seems to be impossible to me. The problem seems to be randomly appearing whether there is a lot of people logged in or not, whether there is a lot of content or avatars on the sim or not. I have a very fast computer and internet connection. Maybe it depends on the amount of people using groups at the moment or loading group information like memberlists. Then it is unrelated to the concurrency and client resources. Regarding the landmarks, when I click an attachment, then landmark window opens and it shows “loading”. But it never loads. I have to switch back to the landmarks folder and locate the landmark there to open it again. Rather confusing for newbies.
    Besides, I really love your blog. It is always very interesting to read.

    • Thanks for the kind words. 🙂

      I’m using the Dev Viewer 3.2.6 and I’m seeing the LM problem you describe. I too have to open Inventory to use the LM.

      I suggest you add a comment to the JIRA item. As more empirical information accumulates the Lindens will eventually be able to get an idea where the problem is. Of course getting people with the problem to WATCH the item will help too.

  4. Hello, I’m a he 🙂 That post in JIRA was old. Anyway, till this very day i still load every member name of my 53500 people group. Not easy, that’s true, but i do load it every day because i have to give rights to members. To be able to do it i use Singularity viewer now, when group grow so large, but before i used Hippo till number of members was below 50k. I think Singularity is low resources consumer and that helps me for this “job”.
    I still hope LL will do something to help the others to load them even smaller groups, but post in JIRA is so old and they did nothing as i see. So i was forced to adapt my “method” to my needs. I post here just for those who need a chance to help them members and sure, them group to be organised in the best way.
    Members names are in a file name “name.cache” in the cache folder of the viewer. Mine has around 18kb because of group size. So, because of this, i clear my cache folder regularly, to be sure i will load it in good condition. More names will make the name.cache file to be bigger to be uploaded / downloaded when you log and try to load members. During the loading group members names period i think that file is checked and write by LL server. At this point, in my opinion, loading of members is related with this communication and with both computers involved, mine and LL server. By experience, when i want to load members:
    1. I use to log in fly mode, with all huds detached, closed mini-map, inventory, communicate, radar or any other tab
    2. into a really low lag sim, I mean in some mainland empty sim with only water, at coordinates of that location, meaning SIM name/x/y/z, where x and y will be good to be 128, and z to be the max limit accepted (max z is 8192) ex. Reynolds/128/128/8191
    3. I go directly to my group, at members tab, type in search field zzzzzzzzzzzzzzzzz and push search
    4. after few seconds group members will start loading, usually in 3 steps and i wait till the last step will finish. If group members will not load after the 3rd step, i push the “Refresh” button to try again. Here you need a lot of patience till you’ll be able to load it. If you did but without some group members names, never use the refresh button in this case, use the refresh button only in case that group members as number didn’t load 100%, else you have to push only “Search” or “Show All” buttons. First time when you’ll try this, after a cache clearance, will take you a lot of time (sometimes for me and my group it takes 2 or more hours), but next times will take you few minutes or less. Between alternate of pushing “Search” or “Show All” buttons, i use to fly to any close sim to load members names faster than 2 hours and i it really helps. Anyway, after i load them full with names, i use to log out because in this way, the name.cache file will be saved and till the next cache clearance (not less than 2 weeks), I will load members faster.
    If some of the “big groups” owners / managers / admins will find this helpful, till LL will really find the way to help them, i’ll be glad i was useful. If will not help them as it works for me and my admins/managers, I am really sorry, but at least they’ll know they tried a way that works for others. I wish all of them just good luck!

  5. I have found a Partical Work Around for this issue, which may also lead to a fix.

    Metabolt and Radagast Text Viewers do not Load the list of names. They CAN load and mangage the list in a different window – although the list (over 10,000 names) does not load there either.

    BUT, if you send a Group Notice, Metabolt and Radagast Text Viewers dont seem to care wether the list is loaded or not. It simply accepts your notice and attachment then sends it off to the LL server to be sent…(the server already knows your list, regardless of how large it is).

    We have tested and used this workaround many times over the past few days. Testing with Alts and Real Group Members revealed that they all actually got the notification. Out list is almost 15,000.

    It also seems LL server does not care if your Metabolt or Radagast Text Viewers have loaded the lists and for that matter, likely the same for any viewer. This means that if the “List Counter” loading requiremment of SL Viewer and TPVs were also removed from the Send Notice section of the applicaion, we may find that group notifications actually work quite well.

    However, this does not cure the problem for other uses of the Groups system – such as Group Join, Management, Group Join Bots, Cleaning & Removal etc, so there still issues that need to be dealt with there.

    This workaround will allow users with very large lists (over 10,000) to at least send out group notices and use the list to communicate with valuable customers and members.

    Happy Holidays – Aprille Shepherd

  6. I will add that, based on Henri’s post (above) we tested the system with many viewers (SL, TPV and Text), machines (XP, Vista 32, Win 7 32, Win7 64), routers (4 Linksys/Cisco/Siemens) and internet connections (DSL and Cable). No combonation worked. However, we did through this testing, discover the “Send Notifications Workaround” that can be used with Metabolt or Radagast above.

Leave a Reply

Your email address will not be published. Required fields are marked *