Locations Plugin

It’s about the same, 8 seconds or so :slight_smile:

OK so that’s server side and not much I can do about it.

Can you look at CPU and memory use when it’s running?

You might have to throw some bigger hardware at it?

Thank’s Robert :slight_smile:

Idle most of the time:

Under load when hitting that URL:

I only upgrade the hardware last week to double the previous spec, I’ll have to leave it at that :slight_smile:

Thanks again!

1 Like

Ideally we’d have some streaming solution that just sent the clusters and dug into those as you zoomed in.

If anyone wants to fund that I’m available to discuss, but that’s far from a simple job, I suspect - I’m not even sure we can use the Leaflet plugin as is …

PR welcome.

1 Like

Does performance improve the second time you view it?

It would make sense if this was cached at the very least …

1 Like

No, it’s the same every time :slight_smile:

1 Like

OK so in this mode, it’s not being cached at all then :astonished:

I’m not sure how much influence I can have on that, but it’s using the “Store” so I’m a little surprised …

1 Like

No worries, appreciate you looking at it :smiley:

It’s odd not to cache this at least once a day imho.

but I guess you are unlikely to want to look at it more than once a day, so moot?

Remember that Chatbot can tell you who is nearby a location or specific User.

I’m unsure how many times a day our members might look at the map :slight_smile:

Random thought, is the caching a setting that might be off? :thinking:

About 4 seconds to load ~1800 members on our map using the Nominatim provider and about 3 seconds to load the /directory_items.json?period=location query

2 Likes

@merefield I made a PR, please review

1 Like

Thanks I’ll review!

1 Like

I can’t really justify looking at this in detail without funding as your sites are outliers.

One thing you can look into if you have the motivation and time is track down the database queryplan that is running when /directory_items.json?period=location is running on your server and share that with the community.

There is an index on the locations_user table, but it may not be being used, as its basically two large tables being “zipped” together, so PSQL may just give up on using the index whilst performing the INNER join.

The query is simpler these days, though, since the Ember 5 work, so theoretically should be faster.

You could also please investigate how long that query is taking. It might be a serialisation issue not a query performance issue.

Another thing we could look at is simplifying the serialisation as there’s probably a lot of unnecessary data being downloaded.

            "id": 42348,
            "user": {
                "id": 4928,
                "username": "bob",
                "name": "",
                "avatar_template": "/user_avatar/mysite.org/bob/{size}/348_2.png",
                "title": null,
                "trust_level": 2,
                "geo_location": {
                    "lat": "5.5219",
                    "lon": "-0.564",
                    "address": "London, Greater London, England, United Kingdom",
                    "countrycode": "gb",
                    "city": "London",
                    "state": "England",
                    "country": "United Kingdom",
                    "postalcode": "",
                    "boundingbox": [
                        "51.2867601",
                        "51.6918741",
                        "-0.5103751",
                        "0.3340155"
                    ],
                    "type": "administrative"
                }
            }

We don’t need two thirds of this. I will accept a PR to cut this down. Or you can fund me to look at this.

Another thing you might want to look at is how you might beef up your PSQL server somehow. Can you migrate to a much faster VPS somehow? However, I think we should do due diligence on the efficiency of code first before you consider this.

If you are prepared to fund some performance tuning work here let me know or PR welcome!

I have a confusing support request :slight_smile:

I’ve got two “Members Map” options in my burger menu today, and I’m not sure how the second one is getting in there.

I renamed them all this morning to help me track down where it might be coming from, hence 1 and 2 that you’ll see in this screen shot.

Here’s how it looks:

Members Map1 is the one I want to keep, and it got there because I put it there by clicking on Customise:

The settings for the Locations plugin are set to not add it to the menu. If I toggle this, it appears as the word Map, so it’s definitely not this one:

If I customise the Text for my Discourse, and search for Members Map then I get two results. I renamed these to both 2 and 3 to aid with the trace.

You’ll see here, it’s the 2 one that’s also appearing in my menu.

Does anyone know what js.directory.map.title is and how it might be getting in my menu?

The only thought I had was that last year we used to run the Custom Hamburger Menu Links theme but I removed it when we switched to the new Discourse menu layout. Could something have been left over from that perhaps? :thinking: If so I’ll move this post elsewhere :blush:

See Locations Plugin - #1015 by merefield

Again, PR welcome or you can fund me to improve this.

Workaround for now: don’t add your own entry, or delete the current one with CSS.

Ah, right, at least I know I’m not going mad :smiley:

Thanks Robert!

1 Like

If it helps anyone else, I’ve added this to hide it:

/* Hide the second Users Map link from the site menu - REF: https://meta.discourse.org/t/locations-plugin/69742/1037 */
.sidebar-section-link-wrapper {
     .sidebar-section-link {
         &[data-link-name="users map"] {
         display: none;
         }
     }  
}
3 Likes

Question: Entire entered addresses used to show up under the topic header next to the map icon. Lately only the map icon shows up but not the address itself. Is this a recent change? Is there a way to have the address show up again? Thanks!