Ответ 1
В то время как у меня нет конкретного ответа на ваш вопрос, у меня есть опыт работы с проблемами процессора для нашего приложения meteor производства, поэтому я могу дать вам список вещей для расследования.
-
Перейдите к последней версии метеора и соответствующей версии node (см. журнал изменений). На момент написания это метеор 0.8.2 и node 0.10.28.
-
Прочитайте this и эту статью. Последнее делает большой вывод, что вы действительно должны всегда пытаться откладывать активацию подписки, пока они вам не понадобятся. В частности, вам может не понадобиться публиковать что-либо для пользователей, которые не вошли в систему. По моему опыту, проблемы с метеорным процессором имеют все, что связано с подписками.
-
Будьте осторожны с
observeиobserveChanges. Это дорогой и их легко использовать. В частности:- Убедитесь, что вы вызываете
stop()на своих дескрипторах, когда они больше не нужны (подумайте об использовании пакета, например publish-with-relations, чтобы это делается для вас). - Выбираем только те коллекции и поля, которые вам абсолютно необходимы. Наблюдайте за работой, постоянно различая объекты (требуется много CPU). Чем меньше и меньше объектов у вас есть, тем меньше приходится вычислять.
- Убедитесь, что вы вызываете
-
/li >Рассмотрите возможность использования smart-collections до отставной.Используйте oplog tailing - это может привести к разнице в производительности и производительности процессора в ночном и дневном времени в вашем приложении. -
Считайте, что некоторые вещи не реагируют (также упоминается в статьях выше). Для нас это была большая победа. У нас было одно чрезвычайно дорогое соединение, которое использовалось на двух часто доступных страницах на сайте. Когда он дошел до того, что процессор был привязан на 100% каждые 30 минут, я отказался от реактивности для этого элемента и просто присоединился к серверу и отправил данные клиенту с помощью вызова метода. Я также создал кеширующий кэш на стороне сервера для этих результатов и сохранил их пользователем (особая благодарность Мэтту Дебергалису за это предложение).
-
Сделайте профилактический ночной перезапуск. У меня есть задание cron, которое сообщает
foreverперезапустить наше приложение один раз в день в середине ночи. Это приводит к снижению КПД с ~ 10% до 1%. Это похоже на черную магию, но тот факт, что использование ЦП изменяется после reset, заставляет меня думать, что это хорошая идея.
Обновленные мысли (1/13/14)
-
Мы перешли на oplog tailing, как только он был доступен (метеор 0.7), и это имело большое значение. Обратите внимание, что для получения доступа к oplog вам, вероятно, потребуется либо разместить свой собственный db, либо запустить выделенный экземпляр на хостинг-провайдере по вашему выбору. Я также рекомендую добавить пакет
facts, чтобы действительно сказать, работает ли он. -
В
publish-with-relationsобнаружена утечка памяти, и с этой точки зрения версия атмосферы (v0.1.5) не была затронута, чтобы отразить эти изменения. Если вы используете его в производстве, я настоятельно рекомендую проверить версию HEAD и запустить ее локально. -
Мы перестали делать ночные перезагрузки пару недель назад. Пока все было хорошо (пальцы скрещены).
Обновленные мысли (7/2/14)
-
Несколько месяцев назад мы переключились на использование Elastic Deployment на mongohq. Это было доступно, производительность была отличной, и у них даже есть сообщение в блоге, в котором рассказывается, как включить хвостовое оперение.
-
Я настоятельно рекомендую проверить kadira, чтобы помочь в диагностике проблем с производительностью в вашем приложении. Также ознакомьтесь с статьями академии, в которых есть много хороших советов.