Оригинал http://code.google.com/appengine/forum/?place=msg%2Fgoogle-appengine%2FHluog1_a3n4%2FuFMhaBWhVi8J

Определения

Экземпляр приложения (Instance) – небольшое виртуальное окружение для запуска вашего кода с зарезервированной памятью и долей процессора.
Внешний экземпляр (Frontend instance) – экземпляр приложения, выполняющий ваш код и динамически масштабирующийся в зависимости от поступающих запросов, но ограниченный по времени обработки запроса.
Фоновый экземпляр (Backend instance) – экземпляр приложения, выполняющий ваш код с ограниченной масштабируемостью, основанной на ваших настройках, теоретически запускается и останавливается по вашей команде.
Очередь запросов (Pending Request Queue) – очередь запросов, ожидающих экземпляра готового их обслужить.
Задержка ожидания в очереди (Pending Latency) – время, которое запрос проводит в очереди запросов.
Планировщик (Scheduler) – Часть инфраструктуры App Engine, которая определяет какой экземпляр должен обрабатывать запрос и когда нужно создать новый экземпляр.

Инфраструктура

Что такое экземпляр приложения (Instance)?
Когда App Engine запускает ваш код – создается маленькая виртуальная среда для выполнения кода с зарезервированной долей процессора и памяти. Например если вы запускаете Java-приложение, то для него стартует новая JVM и в нее загружается ваш код.

Экземпляр приложения в App Engine это аналогия виртуальной машины?
Да и нет – то и другое имеет выделенные обемы памяти и мощность процессора, но в приложении GAE нет накладных расходов на работу операционной системы или других приложений, т.е. для реального использования остается больший процент процессора и памяти. Они так же работают через высокоуровневые интерфейсы, а не через прослойку кода для виртуальных устройств – это позволяет делать сервисы более управляемыми.

Как GAE определяет необходимой количество внешних экземпляр приложения (Frontend Instance)? 
Для каждого запроса планировщик есть ли свободный экземпляр для обработки запроса, должен ли запрос подождать или нужно создать новый экземпляр приложения. Он принимает во внимание количество уже запущенных экземпляров, их пропускную способность и количество запросов в очереди ожидания. Планировщик расчитывает предполагаемое время ожидания для обработки запроса и если оно больше 1 секунды – запускает новый экземпляр приложения. Если планировщик понимает что какой-то из экземпляров больше не нужен – он выключается.

Я должен будут платить за все приложения, которые сейчас показываются в панели администрирования? 
Нет, мы работает над изменением планировщика для оптимизации использования созданных экземпляров приложения, их число должно сократиться. Если вы используете Java и ваше приложение потоко-безопасно – один экземпляр приложения может обслуживать несколько запросов одновременно. То, что вы видите сейчас можно рассматривать как верхнюю границу количества экземпляров.

Как я могу контролировать количество запущенных экземпляров? 
Вместе с новым планировщиком появятся настройки того сколько много экземпляров приложения будет запускаться для обработки запросов. Более подробную информацию можно найти ниже, в вопросе “Какие нововведения сделаны в новом планировщике?”

Как я могу понять – сколько запросов может обработать один экземпляр приложения?
Самый значимый фактор – задержка приложения в обработке запросов. Если запросы обрабатываются быстро – один экземпляр может обслуживать много запросов, к тому же Java поддерживает параллельную обработку запросов, т.е. приложение сможет обрабатывать несколько запросов одновременно., это может значительно снизить количество необходимых экземпляров приложения.

Что делать с параллельной обработкой запросов для Python? Потребуются ли изменения кода? 
Параллельность Python будет решена вместе с выпуском Python 2.7 для GAE. Мы услышали отзывы пользователей Python, которые волнуются и думают переходить ли на Java, т.к. там поддерживается параллельная обработка запросов. Мы сделали поправку в ценах – пока Python 2.7 не готов мы будем предоставлять для Python вдвое меньшие экземпляры приложения (вдвое дешевле). Смотрите вопрос “Какие изменения нужно внести в код для использования Python 2.7”

Как много запросов может обрабатывать один экземпляр приложения? 
Одно-поточный экземпляр (python или java) одновременно может обрабатывать 1 запрос. Дальше это количество запросов обратно-пропорционально задержке ответа. Например для задержки 10 мс = 100 запросов/секунду/экземпляр, для задержки 100 мс = 10 запросов/секунду/экземпляр и т.д. Много-поточные приложения могут обслуживать несколько запросов одновременно. Здесь скорость обработки связана с требованиями к процессору. Для экземпляра B4 (примерно 2.4ГГц): 10 Мегациклов/запрос = 240 запросов/секунду/экземпляр, 100 Мегациклов = 24 запроса/секунду/экземпляр. Конечно эти числа в идеальной ситуации, но это поможет понять как рассчитывать производительность приложения. Много-поточные приложения сейчас можно сделать только на Java, поддержку Python мы планируем в этом году, но позже.

Почему Google будет считать экземпляры, а не процессорное время, как в предыдущей модели? 
Процессорное время – лишь часть ресурсов, используемых App Engine. Когда запускается ваше приложение – создается экземпляр приложения, которому доступны максимум процессора и памяти, которые приложение может использовать. Даже когда процессор не работает, а ждет нового запроса – экземпляр продолжает “использоваться”, для Google это стоит денег. В текущей модели приложения с большим временем ожидания (другими словами те, которые долго простаивают ничего не делая) не в состоянии масштабироваться, т.к. это будет очень дорого для Google. Это изменение позволит разработчикам запускать разные типы приложения и при этом оплачивать все используемые ресурсы.

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

Как будет работать режим “всегда включено” с новой моделью? 
Когда GAE покинет предварительную стадию и станет полноценным продуктом все платные приложения смогут указать минимальное количество экземпляров, которые будут находиться в состоянии ожидания. Опция “Всегда включено” предназначена для того чтобы снизить начальную задержку при ответе приложения. Для большинства приложений одного экземпляра в состоянии ожидания будет достаточно (особенно учитывая параллельное выполнение запросов). Это означает, что большинство клиентов смогут настроить минимальное количество экземпляров в режиме ожидания – 1 и это будет укладываться в предоплаченные лимиты – 24 часа в сутки.

Какие нововведения сделаны в новом планировщике?
В новом планировщике добавлены 4 ключевые возможности:
– Минимальное количество экземпляров в режиме ожидания (Min Idle Instance): Задает количество экземпляров, которые будут запущены, даже если приложению нечего делать и ждут новых запросов. Эта опция доступна только для платных приложений
– Максимальное количество количество экземпляров в режиме ожидания (Max Idle Instance): Определяет максимальное количество экземпляров, которое планировщик может сохранять в ожидании новых запросов. Низкие значения помогут сэкономить, но при скачке трафика потребуется снова запускать новые экземпляры и за это платить.
– Минимальное время ожидания (Min Pending Latency): Минимальное время, которое запрос будет находиться в очереди ожидания прежде чем планировщик запустит новый экземпляр.
– Максимальное время ожидания (Max Pending Latency): Определяет как долго запрос может быть в очереди ожидания. Если ожидание достигло этого значения тут же будет выделен экземпляр для обслуживания этого запроса.

Как нововведения планировщика отразятся на ценах и счетах?
– Минимальное количество экземпляров в режиме ожидания (Min Idle Instance):  Увеличение этого параметра увеличит оплату, увеличивая количество всегда запущенных экземпляров даже во время простоя приложения.
– Максимальное количество количество экземпляров в режиме ожидания (Max Idle Instance): Уменьшение этого параметра уменьшит оплату и вы не будете платить за лишние экземпляры в режиме ожидания. Эта опция служит только как подсказка планировщику, но вы не будете переплачивать если планировщик ее проигнорирует. Например вы задали максимальное количество экземпляров ожидания 5, а планировщик на некоторое время оставил в режиме ожидания 16 экземпляров, вы будете платить только за 5.
– Минимальное время ожидания (Min Pending Latency): Уменьшение этого параметра увеличит оплату, т.к. планировщик будет запускать новые экземпляры более агрессивно.
– Максимальное время ожидания (Max Pending Latency): Увеличение этого параметра уменьшит оплату, т.к. планировщик будет чаще использовать уже запущенные экземпляры вместо создания новых.

В чем разница между экземплярами по требованию (On-demand Instances) и зарезервированными экземплярами (Reserved Instances)?
Для экземпляров по требованию – вы не обязуетесь их использовать, а платите по факту только за использованные часы. Для зарезервированных экземпляров вы обязуетесь оплатить определенное количество часов работы приложения в неделю и их нужно будет оплатить независимо от того использовали вы их или нет. Это не означает, что они должны быть запущены всё время.

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

С какой точностью будет считаться время работы приложения? Например если оно будет работать 5 минут я заплачу $0.08/60 * 5?
Ответ: Оплачивается время работы экземпляра приложения и еще 15 минут ожидания (пока планировщик не выключит его). Например если у вас экземпляр приложения по требованию работал 5 минут, то вы заплатите за 5 + 15 минут или $0.08/60 * 20 = 2.6 цента. Кроме того если экземпляр остановлен и затем запустится в течение 15 минут, то платеж за запуск будет считаться только 1 раз, а время простоя будет оплачиваться так как если бы экземпляр был запущен. Например: экземпляр обрабатывает запросы 5 минут, затем на 4 минуты выключается, потом снова 3 минуты обрабатывает запросы, вы будете платить (5+4+3)+15 минут, т.е. $0.08/60*25 = 3.6 цента.

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

Основные экземпляры (Frontend instances) смогут обрабатывать заданий Cron и очереди задач? 
Да, это поведение по умолчанию.

Переносятся ли зарезервированные часы на следующую неделю?
К сожалению нет. Если вы обязались использовать определенное количество часов за неделю вы будете их оплачивать независимо от того использовали вы их или нет.

Рабочее окружение Go поддерживаем параллельную обработку запросов? 
Пока нет.

Какие изменения нужно внести в код для использования Python 2.7?
Обычно код для Python 2.5 будет работать с Python 2.7, но есть несколько важных изменения, которые могут потребоваться:
– Будет использоваться Django 1.2: Сейчас по умолчанию используется 0.96 (в том числе, когда используются шаблоны в webapp). Поскольку Python 2.7 будет новой средой исполнения мы не планируем дальше поддерживать эту устаревшую версию. Мы будем поддерживать как минимум Django 1.2. Вам нужно к этому подготовиться, лучший способ – проверить как ваш код работает с Django 1.2, инструкцию можно посмотреть тут.
– Поддержка Python 2.7: понятно, что это само собой разумеется, но мы все равно скажем – нужно проверить совместимость вашего кода с Python 2.7.

Как будут в Python 2.7 будут обрабатываться параллельные запросы?
Python 2.7 будет новой средой выполнения GAE. Параллельные запросы будут работать в потоках, так же как сейчас работает среда выполнения Java.
– Используйте WSGI-совместимый фреймворк: для использования многопоточного режима вы не сможете использовать CGI. Для параллельности можно использовать только WSGI, в том числе webapp, который входит в состав Google App Engine.
– Потокобезопасность: Поскольку в Python 2.7 использует потоки для параллельной обработки запросов для их использования ваш код должен быть потокобезопасным.
– Все изменения, которые нужно сделать с кодом для работы в Python 2.7 перечислены в предыдущем ответе.

Цены

$9/приложение/месяц это абонентская плата или минимальный платеж? 
Основываясь на отзывах мы изменили абонентскую плату $9 на минимальный платеж $9. Другими словами вы можете пользоваться платными ресурсами в объеме $9 и при этом вы не должны будете доплачивать что-то е ежемесячному платежу в $9. $500/аккаунт/месяц остается как абонентская плана на покрытие операционных расходов.

Большинство клиентов должны будут изменить тип приложений на платный? 
Нет, мы ожидает, что большая работающих сейчас приложений сможет остаться в рамках бесплатных квот.

Смогут ли существующие приложения продолжать использовать текущую модель расчетов? 
Нет, все приложения будут переведены на новую модель расчетов, когда App Engine станет официальным продуктом.

Увеличатся ли платежи у большинства клиентов? Если да, то почему Google увеличивает цены для App Egnine? 
Да, у большенства клиентов, которые платят счета увеличатся. Во время предварительной фазы работы App Engine мы смотрели сколько это стоит, исследовали основные модели использования. Мы должны изменить цены сейчас, потому что GAE становится официальным продуктом Google и должен иметь модель устойчивого дохода на долгие годы.

Будут ли в будущем корректироваться цены в связи с падением цены на оборудование?
Нет, у нас в планах нет дальнейшего изменения цен (в любую сторону).

API

Как считались цена на API? 
Для большей части API стоимость останется примерно той же, что сейчас, просто вместо процессорного времени мы будем считать количество операций, для Channel API это будет стоить $0.01/100 каналов. Это примерно столько, сколько сейчас оплачивается как часть процессорного времени. API для работы с хранилищем подробно описано дальше.

На странице с ценами для некоторых API стоят галочки вместо цен, что это значит? 
Эти API бесплатны для использования с App Engine.

Как будет работать новая модель для XMPP? Сколько будут стоить статусные сообщения? 
Для XMPP будут тарифицироваться только исходящие сообщения. Входящие сообщения очень похожи на обычные запросы и будет считаться трафик и конечно процесс обработки запроса в экземпляре приложения. Для статусных сообщений будет оплачиваться только трафик. Это почти так же как сейчас, только вы видите процессорное время вместо количества сообщений.

Сколько будет стоить входящая почта? 
Входящая почта будет тарифицироваться как обычный запрос – входящий трафик и время работы экземпляра приложения, так же как это работает сейчас.

Будет ли внешний кеш (Front end cache) формализован и станет ли он частью предлагаемого сервиса? 
Сейчас мы рассматриваем различные варианты, но пока никаких планов нет.

Будут ли письма для администраторов дешевле или бесплатными?
Мы рассматриваем такую возможность. Если вам это важно поставьте звездочку в теме http://code.google.com/p/googleappengine/issues/detail?id=5235.

API хранилища

Какие операции будут оплачиваться?
Будут оплачиваться 3 типа операция:
– Операция записи (запись объекта, удаление объекта, запись индекса), каждая из этих операций будет оплачиваться по цене $0.10 за каждые 100тыс. операций.
– Операция чтения (запрос, получение объекта), каждая операция будет оплачиваться из расчета $0.07 за каждые 100тыс. операций.
– Маленькие операции (Получение ключа, выделение ID), каждая из этих операций будет оплачиваться из рассчета $0.01 за каждые 100тыс. операций.

Будет ли это зависеть от размера объекта?
Нет.

Как в новой модели будут считаться пакетные операции и имеют ли они смысл, например будет ли стоимость db.get(key1); db.get(key2) отличаться от стоимости db.get(key1,key2)?
Пакетное выполнение операций не влияет на их стоимость, но по прежнему работает быстрее, чем отдельные запросы – их нужно использовать для уменьшения времени ответа.

Если я сделаю db.get(key1,key2) и получу 2 объекта – сколько будет посчитано операций?
Будет посчитано 2 операции получения объекта.

Если key2 не существует и я получу только 1 объект – как это будет оплачиваться?
Будет посчитано получение 2-объектов.

Если db.get(key1) получает 5Кб, а db.get(key2) 500Кб – будет ли разница в стоимости?
Нет, стоимость не меняется.

Как в новой схеме выгоднее делать: запросить 1000 ключей и потом взять только 500 нужных объектов или сразу получить 1000 объектов?
Первый вариант более экономный. Получение 1000 ключей + 500 объектов = $0.0001 + $0.00035 = $0.00045, а получение 1000 объектов = $0.0007.

Хранилище

Логи считаются в общем объеме сохраненных данных?
Нет, для каждого приложения хранится ограниченный объем логов и он не входит в квоту.

Варианты использования

Вопрос: Что означает стоимость премиум-аккаунта $500/аккаунт? За Google-Apps-аккаунт? За аккаунт разработчика? За аккаунт владельца приложения?
Ответ: Это платеж с организации (можно сказать что за Google Apps аккаунт, если вы уже клиент Google Apps). Например если вы работаете в gregco.com и у вас премиум-аккаунт, то пользователя gregco.com могут создавать приложения, которые будут оплачиваться с аккаунта gregco.com.

Вопрос: Будут специальные цены для некоммерческого использования?
Ответ: Возможно, сейчас этот вопрос исследуется

Вопрос: Будут ли специальные цены для использования в образовании?
Ответ: Возможно, сейчас этот вопрос исследуется

Вопрос: Будут ли специальные цены для проектов с открытым исходным кодом?
Ответ: Возможно, сейчас этот вопрос исследуется

Ограничения

Вопрос: Если я перенесу приложение в отказоустойчивое хранилище (HR Datastore) это будет означать, что у меня “новое” приложение и у меня будет новая, уменьшенная квота на отправку email? Могу я воспользоваться прежним лимитом в 2000 писем?
Ответ: Да, вы сможете воспользоваться прежним ограничением для приложений, которые переносятся из Master/Slave хранилища в отказоустойчивое.