Является ли пропускная способность процессора в Google App Engine слишком дорогой или это мой код?

Question

Я хотел оценить производительность чтения GAE.Из хранилища данных извлекается около 10 000 объектов.Эти объекты содержат 3 имени свойства (около 16 символов), описание (около 130 символов) и отметку времени.Ничего необычно большого.

Вот что я вижу:

В среднем для считывания 10 тыс. Сущностей требуется около 11 секунд. Не уверен, считается ли это быстрым, медленным илиразумно, но, тем не менее, не слишком увлекательно.

Более интересной находкой является измерение процессоров. Выполнение этой операции чтения 100 раз занимает около 3,0 часов ЦП.Стоимость составляет $ 0,30.

Учитывая, что здесь не используется алгоритм с высокой загрузкой процессора, разве это не делает пропускную способность процессора GAE довольно дорогой?(конечно, он поставляется с 24/7 системными администраторами в форме сценариев Python и т. д. и т. д., но все же ...)

Или это что-то в моем коде Java:

http://github.com/akirekadu/GAE-Evaluation/blob/master/show.jsp

Answer 1

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

Мы отметили, что:

• Указатели стоят дорого. Если вы пишете больше, чем читаете, будьте скупы со своими индексами. Убедитесь, что вы знаете об атрибуте indexed=False в свойствах модели, и обратите особое внимание на то, что автоматически генерируется в index.yaml.

• Если вы читаете больше, чем пишете, тогда может иметь смысл множество мультииндексов. Используйте memcache, где вы можете. Используйте группы сущностей, если они имеют смысл.

• API механизма приложений предоставляет вам инструменты, повышающие эффективность. Они очень важны. Если вы пишете 100 строк, использование одного массового вызова put () против 100 отдельных вызовов put () значительно сократит использование ЦП.

Если ваше приложение будет часто выполнять большие операции чтения, как вы описали, вы можете выбрать другое решение (например, VPS, например Slicehost или Linode) или другую модель данных. Каждое приложение будет иметь разные потребности: WRT-диск, процессор, память и т. Д., Поэтому я оставляю расчеты за пределами конверта в качестве упражнения для читателя.

НТН!