Перекрывающиеся подписки в Meteor ухудшают производительность?

Вот моя проблема.

У меня есть приложение, в котором пользователи могут хранить заметки в блокнотах.

В настоящее время, когда пользователь щелкает блокнот, я подписываюсь на публикацию, которая возвращает первые 5 заметок этого блокнота.

Поэтому всякий раз, когда пользователь переходит к новому блокноту, устанавливается новая подписка, и 5 заметок этого блокнота попадают в minimongo. Таким образом, у минимонго в коллекции заметок одновременно только 5 заметок.

Чтобы улучшить взаимодействие с пользователем, я изменил публикацию, поэтому при первоначальной загрузке всего приложения я подписываюсь на публикацию, которая возвращает все блокноты и первые 5 заметок для каждого блокнота. Итак, теперь в minimongo у нас всегда есть (5 x (количество блокнотов)) количество заметок.

Таким образом, первоначальная загрузка немного тяжелее, но я надеюсь, что после этого навигация между блокнотами станет намного быстрее.

Поэтому при загрузке я подписываюсь на myInfo, который возвращает блокноты пользователей и первые 5 заметок для каждого блокнота.

Затем, когда вы фактически щелкаете блокнот, я подписываюсь на myNotepadInfo, который также возвращает первые 5 заметок блокнота. Поскольку первоначальная подписка уже получила эту информацию, ни один из документов в minimongo фактически не меняется. Но я все еще хочу подписаться на myNotepadInfo, потому что у меня есть механизм загрузки дополнительных заметок, который зависит от этой подписки в шаблоне.

Итак, мое приложение полностью работает с этими изменениями, но я не уверен, что происходит под капотом, и действительно ли этот метод помогает производительности. Я не могу заметить конкретной разницы в том, как загружаются блокноты после изменения.

Так что в основном у меня есть вторая подписка, которая перекрывает первоначальную подписку.

Мне кажется, так как вторая подписка перекрывается с начальной, она должна передавать клиенту меньше документов, поэтому она должна быть быстрее?


person Nearpoint    schedule 11.10.2016    source источник
comment
Из документации по метеорам: 'Однако, если следующая итерация вашей функции запуска подписывается на один и тот же набор записей (то же имя и параметры), Meteor достаточно умен, чтобы пропустить расточительную отмену подписки/повторную подписку.' Я не думаю, что это хорошая практика - подписываться на все при запуске. Время загрузки сильно увеличится с большим количеством блокнота. Вот почему подписка для. Если вы хотите реализовать динамическую загрузку/поиск, easy:search – это хороший выбор.   -  person Max G.    schedule 11.10.2016


Ответы (1)


Два ключевых вопроса для этого будут: (1) сколько данных вы отправляете клиенту?; и (2) сколько пользователей вы ожидаете?

Второй пункт требует некоторых пояснений. Ключевым компонентом в текущей (2016 г.) pub-архитектуре Meteor является то, что клиентские подписки регистрируются и отслеживаются на сервере. Каждая дополнительная подписка, которую нельзя использовать повторно (т. е. не дублирующая другую подписку), увеличивает требования к ЦП для приложения. Здесь это звучит так, как будто каждый пользователь «владеет» блокнотом (хотя это может быть и не так). Если это так, это будет означать низкое повторное использование подписки — каждому пользователю потребуется независимая подписка для получения его/ее блокнота, поскольку они не могут быть повторно использованы другими пользователями. Таким образом, две подписки на блокноты на пользователя фактически удвоят долю ЦП приложения, которая приходится на подписки на блокноты.

Это не обязательно плохо. Если ваше приложение предназначено для администрирования, внутренних служб или просто для меньшего числа пользователей, это может не иметь заметного значения. Для приложения, ориентированного на потребителя, которое надеется/ожидает большое количество пользователей, это был бы плохой выбор.

Хорошая статья Кадиры о повторном использовании наблюдателя здесь и я также рекомендую их (платные) статьи Bulletproof Meteor.

Наконец, вы можете ознакомиться с некоторыми инструментами Kadira, предназначенными для решения этих проблем, Sub Manager. и Быстрый рендеринг. Вы должны проверить, активно ли они все еще поддерживаются, хотя - я этого не делал.

person Jeremy S.    schedule 11.10.2016
comment
Привет, Джереми, спасибо, это полезно. Пользователь подписывается на собственную информацию. В публикации я возвращаю блокнот и заметки, используя this.userId в запросе. Как бы я еще это сделал? Я не понимаю, похоже, это был бы единственный способ подписаться на свои данные. Невозможно настроить его так, чтобы пользователи делились подпиской. Я что-то упустил? - person Nearpoint; 12.10.2016
comment
Я не думаю, что вы что-то упускаете. Если вы делаете что-то вроде return Notepads.find({userId: this.userId}) в своей публикации, вы не сможете повторно использовать наблюдателей, поэтому вам лучше использовать первую из двух стратегий, изложенных в вопросе. Две подписки на блокнот на пользователя быстрее приведут к проблемам с ЦП, что является основным узким местом масштабирования Meteor. (Единственное, что немного повысит эффективность, — это выполнить нулевую проверку для this.userId, на которую есть ссылка в статье Kadira, указанной выше, и это на самом деле не решает основную проблему.) - person Jeremy S.; 13.10.2016