Почти то же самое, около 8 секунд 
Ладно, это проблема на стороне сервера, и я мало что могу с этим сделать.
Можешь посмотреть на использование процессора и памяти, когда он работает?
Возможно, придется подключить более мощное оборудование?
Спасибо, Роберт
В основном простаивает:
Под нагрузкой при обращении к этому URL:
Я обновил оборудование на прошлой неделе, удвоив предыдущие характеристики, так что пока оставлю всё как есть
Ещё раз спасибо!
1 лайк
В идеале нам нужно было бы решение для потоковой передачи, которое просто отправляло бы кластеры и углублялось бы в них по мере приближения.
Если кто-то хочет профинансировать это, я готов обсудить детали, но, боюсь, это далеко не простая задача — я даже не уверен, что мы можем использовать плагин Leaflet в его текущем виде…
PR приветствуются.
1 лайк
Улучшается ли производительность при повторном просмотре?
По крайней мере, было бы логично, если бы это кэшировалось…
1 лайк
Нет, это одно и то же каждый раз
1 лайк
Окей, значит в этом режиме кэширование вообще не используется 
Не уверен, насколько сильно я могу повлиять на это, но раз используется “Store”, я немного удивлён…
1 лайк
Не волнуйтесь, спасибо, что посмотрели 
По-моему, странно не кэшировать это хотя бы раз в день.
Но, полагаю, вы вряд ли захотите смотреть на это чаще раза в день, так что это уже не имеет значения?
Помните, что Chatbot может сообщить, кто находится рядом с определённой локацией или конкретным пользователем.
Не уверен, сколько раз в день наши участники могут просматривать карту
Случайная мысль: может быть, кэширование — это настройка, которая отключена? 
Загрузка ~1800 участников на нашей карте с использованием провайдера Nominatim занимает около 4 секунд, а запрос /directory_items.json?period=location — около 3 секунд.
2 лайка
@merefield Я отправил PR, пожалуйста, проверь.
1 лайк
Спасибо, я изучу!
1 лайк
Без финансирования я не могу обосновать детальный анализ этого вопроса, так как ваши сайты являются выбросами.
Одна из вещей, которую вы можете изучить, если у вас есть мотивация и время, — это отследить план выполнения запроса к базе данных, который выполняется, когда на вашем сервере вызывается /directory_items.json?period=location, и поделиться им с сообществом.
На таблице locations_user есть индекс, но возможно, он не используется, так как это по сути слияние двух больших таблиц, и PSQL может просто отказаться от использования индекса при выполнении INNER JOIN.
Однако сам запрос стал проще благодаря работе над Ember 5, поэтому теоретически он должен выполняться быстрее.
Также вы могли бы проверить, сколько времени занимает выполнение этого запроса. Возможно, проблема не в производительности запроса, а в сериализации.
Еще один вариант — упростить сериализацию, так как, вероятно, загружается много избыточных данных.
"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"
}
}
Нам не нужны две трети этих данных. Я приму PR, который сократит этот объем. Или вы можете профинансировать мою работу по этому вопросу.
Также стоит рассмотреть возможность улучшения производительности вашего сервера PSQL. Возможно ли миграция на значительно более быстрый VPS? Однако, по моему мнению, прежде чем рассматривать этот вариант, следует провести тщательную проверку эффективности кода.
Если вы готовы профинансировать работу по оптимизации производительности, дайте мне знать. Также приветствуются PR!
У меня есть запутанный запрос в службу поддержки
Сегодня в моём меню-бургере появились два варианта «Members Map», и я не понимаю, откуда взялся второй.
Я переименовал их сегодня утром, чтобы отследить источник появления, поэтому в этом скриншоте вы увидите обозначения
1и2.
Вот как это выглядит:
Members Map1 — тот, который я хочу оставить. Он появился там, потому что я добавил его вручную, нажав «Настроить»:
Настройки плагина Locations установлены так, чтобы не добавлять его в меню. Если я переключу эту опцию, он появится как слово Map, так что это точно не он:
Если я изменю Text для своего Discourse и поищу Members Map, то получу два результата. Я переименовал их в 2 и 3, чтобы помочь с отслеживанием.
Как видно здесь, именно вариант 2 также появляется в моём меню.
Не знает ли кто-нибудь, что такое js.directory.map.title и как он мог попасть в моё меню?
Единственная мысль, которая у меня возникла, заключается в том, что в прошлом году мы использовали тему Custom Hamburger Menu Links, но удалили её, когда перешли на новую раскладку меню Discourse. Возможно, что-то осталось от неё? Если так, я перемещу этот пост в другое место 
Смотрите Locations Plugin 🌍 - #1015 by merefield
Опять же, приветствуется pull-запрос, или вы можете профинансировать моё улучшение этого.
Временное решение: не добавляйте свою запись или удалите текущую с помощью CSS.
2 лайка
Ах, хорошо, по крайней мере я знаю, что не схожу с ума
Спасибо, Роберт!
2 лайка
Если это кому-то ещё поможет, я добавил следующий код, чтобы скрыть его:
/* Скрыть вторую ссылку «Карта пользователей» из меню сайта - ССЫЛКА: https://meta.discourse.org/t/locations-plugin/69742/1037 */
.sidebar-section-link-wrapper {
.sidebar-section-link {
&[data-link-name="users map"] {
display: none;
}
}
}
4 лайка
Вопрос: Раньше все введенные адреса отображались под заголовком темы рядом с иконкой карты. В последнее время отображается только иконка карты, но не сам адрес. Это недавнее изменение? Можно ли вернуть отображение адреса? Спасибо!
1 лайк
Роберт, планируете ли вы добавить поддержку отображения карты всего сайта на основе IP-адресов всех пользователей?
1 лайк