Использование ресурсов Google Go против Python и Java в Appengine

Question

Будет ли Google Go использовать меньше ресурсов, чем Python и Java в Appengine? Время запуска экземпляра для запуска быстрее, чем время запуска Java и Python?

Загружается ли программа go в виде двоичных файлов или исходного кода, а если она загружается в виде исходного кода, то она компилируется один раз или при каждом запуске экземпляра?

Другими словами: выиграю ли я от использования Go в движке приложения с точки зрения затрат? (только с учетом стоимости ресурсов приложения, а не времени разработки)

Answer 1

Будет ли Google Go использовать меньше ресурсов, чем Python и Java в Appengine? Время запуска экземпляра быстрее, чем в Java и Python? время запуска?

Да, экземпляры Go имеют меньше памяти, чем Python и Java (<10 МБ). </p>

Да, экземпляры Go запускаются быстрее, чем эквиваленты Java и Python, поскольку для запуска приложения требуется только чтение одного исполняемого файла.

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

Загружается ли программа go в виде бинарных файлов или исходного кода, и если это загружается как исходный код, затем он компилируется один раз или в каждом экземпляре запуск

Программа Go загружается в виде исходного кода и компилируется (один раз) в двоичный файл при развертывании новой версии вашего приложения с использованием SDK.

Другими словами: получу ли я выгоду от использования Go в движке приложения от затрат? перспектива?

Среда выполнения Go определенно имеет преимущество в соотношении производительность / цена, однако это не влияет на цены других API-квот, как описано в ответе Питера.

Answer 2

Стоимость экземпляров является лишь частью стоимости вашего приложения.Я сейчас использую только среду выполнения Java, поэтому я не знаю, насколько более или менее эффективными будут вещи с Python или Go, но я не думаю, что это будет на несколько порядков иначе.Я знаю, что случаи не единственные расходы, которые вы должны учитывать.В зависимости от того, что делает ваше приложение, вы можете обнаружить, что затраты на API или хранилище более значительны, чем незначительные различия между средами выполнения.Все затраты на API будут одинаковыми с любой используемой средой выполнения.

Язык "может" повлиять на эти затраты:

• Экземпляры по требованию
• Зарезервированные экземпляры внешнего интерфейса
• Резервные копии

Затраты, не зависящие от языка:

• Высокое хранилище данных репликации (за гигабайтсохранено)
• Исходящая пропускная способность (за гигабайт)
• API хранилища данных (за операции)
• Авария API Blobstore (за гигабайт)
• API электронной почты (по электронной почте)
• API XMPP (для каждого раздела)
• API канала (для каждого канала)

Answer 3

Вопрос в основном не имеет значения.

Минимальный объем памяти для приложения Go меньше, чем у приложения Python, то есть меньше, чем у приложения Java.Все они стоят одинаково для каждого экземпляра, поэтому, если ваше приложение работает лучше с дополнительным пространством кучи, эта проблема не имеет значения.

Время запуска Go меньше, чем время запуска Python, которое меньше времени запуска Java.Если у вашего приложения нет особой причины для прохождения большого количества циклов запуска / выключения экземпляра, это не имеет значения с точки зрения затрат.С другой стороны, если у вас есть приложение, которое исключительно взрывное в очень короткие периоды времени , время запуска может быть преимуществом.

Как упоминалось другимиответы, многие затраты одинаковы для всех платформ - в частности, операции с хранилищами данных.В той степени, в которой Go против Python против Java будет влиять на счет за часы работы экземпляра, он связан с:

• Создает ли ваше приложение много мусора?Для многих приложений самая большая вычислительная стоимость - сборщик мусора.У Java на сегодняшний день самый зрелый GC, и базовые операции, такие как сериализация, значительно быстрее, чем с Python.Сборщик мусора в Go, похоже, является постоянным предметом разработки, но из беглого поиска в Интернете, кажется, не является предметом гордости (пока).Java (скомпилированные JIT) и Go, вероятно, лучше, чем Python для математических операций.

Все три языка имеют свои достоинства и проклятия.По большей части вам лучше позволить другим вопросам доминировать - с каким языком вам нравится работать больше всего?

Answer 4

Это, вероятно, больше о том, как вы распределяете ресурсы, чем о вашем выборе языка. Я читал, что GAE был построен независимо от языка, поэтому, вероятно, нет никакого встроенного преимущества для любого языка, но вы можете получить преимущество от выбора языка, который вам удобен и мотивирован. Я использую python, и то, что сделало мое развертывание намного более рентабельным, это обновление до python 2.7, и вы можете сделать это обновление, только если вы используете правильное подмножество 2.6, что хорошо. Поэтому, если вы выбираете язык, который вам удобен, скорее всего, вы получите преимущество от своей способности использовать язык, а не сам язык + комбинированная среда.

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

Мои приложения маленькие до средние размера и стоят как ничего:

Answer 5

Я не использовал Go, но я сильно подозреваю, что он будет загружать и выполнять экземпляры гораздо быстрее и использовать меньше памяти исключительно потому, что он скомпилирован. Судя по всему, из группы я считаю, что Python более отзывчив, чем Java, по крайней мере, во время запуска экземпляра.

Время загрузки / запуска экземпляра важно, потому что, когда на ваш экземпляр попадает больше запросов, чем он может обработать, он раскручивает другой экземпляр. Это делает этот запрос намного более длительным, возможно создавая впечатление, что сайт обычно работает медленно. И Java, и Python должны запустить свою виртуальную машину / интерпретатор, поэтому я ожидаю, что Go будет здесь на порядок быстрее.

Есть еще одна проблема - теперь доступен Python2.7, Go является единственным вариантом, который является однопоточным (по иронии судьбы, учитывая, что Go разработан как современный многопроцессорный язык). Таким образом, хотя запросы Go должны обрабатываться быстрее, экземпляр может обрабатывать запросы только последовательно. Я был бы очень удивлен, если бы это ограничение продолжалось долго.