Блог

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наконец, вы могли бы ознакомиться с некоторыми инструментами Kadira, которые предназначены для устранения этих проблем, Subs Manager и Fast Render. Однако вам следует проверить, поддерживаются ли они по-прежнему активно — я этого не делал.