Подтвердить что ты не робот

Google App Engine: Memcache или статическая переменная?

Ну, я думаю, у меня есть очень серьезные сомнения здесь:

Я разрабатываю приложение на GAE (Java) и выполняю запрос к хранилищу данных, который возвращает много объектов, поэтому мне нужно кэшировать его. Я использовал memcache, и он работал отлично, но если я сохраню список объектов в статической переменной, весь запрос будет вдвое быстрее, чем использование memcache. Я думаю, потому что я не десериализую сущности все время.

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

Список объектов, которые я пытаюсь кэшировать, - это лучшие (более высокие) посты на прошлой неделе. Я беру этот список и выбираю 5 случайных сообщений и показываю их на нескольких страницах.

Спасибо за помощь!

4b9b3361

Ответ 1

App Engine масштабируется, создавая новые экземпляры вашего приложения по мере увеличения количества пользователей, поражающих его. Как сказал друдру, разные пользователи могут обслуживаться разными экземплярами. В общем, memcache - это самое быстрое место для хранения того, что вы хотите согласовать на глобальном уровне. Однако в вашем случае может быть место для улучшения.

Вы упомянули, что у вас есть список сообщений, и вы случайно выбираете 5 для показа пользователям. Имеет ли значение, если 2 разных пользователя видят другой набор из 5? Если вы все равно выбираете случайных, возможно, это не имеет значения. Затем вы можете сохранить полный список сообщений в memcache и вывести 5 случайных из memcache и сохранить их в статической переменной.

Во-вторых, что именно вы memcaching, и как вы его вытаскиваете? Вы сохраняете целую кучу полных сообщений в memcache, получаете их все, а затем выбираете 5? Может быть, вы могли бы просто скачать список сообщений, выбрать 5, и только получить 5 вам нужно? Если вы считаете это десериализацией, которая замедляет вас, это может помочь. Выполняете ли вы какие-либо обработки на сообщениях после их получения? Если да, можно ли кэшировать результаты этой обработки?

Ответ 2

Вы не можете полагаться на статические переменные (или что-то еще в JVM-памяти), чтобы быть рядом, когда следующий запрос попадает, потому что Google может запускать и останавливать виртуальные машины, когда им это нравится. По внешнему виду они, похоже, предпочитают запускать дополнительные JVM вместо дополнительных потоков в одной JVM, что связывает эту проблему.

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

Я бы также не пытался заходить за пределы памяти с использованием памяти там, должна быть квота о том, сколько памяти вы можете использовать.

Ответ 3

Да, нет гарантии, что ваш экземпляр будет одинаковым для разных пользователей в Интернете. Вы могли бы в конечном итоге постоянно читать это в статике в худшем случае. У memcache есть более высокая гарантия на доступность. Я бы просто использовал memcache, и ваше приложение не должно было иметь проблем с масштабами в будущем.