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

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

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

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

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

4b9b3361

Ответ 1

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

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

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

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

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

Программа

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

Другими словами: могу ли я воспользоваться механизмом Go in app из стоимости перспектива?

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

Ответ 2

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

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

  • Экземпляры по требованию
  • Зарезервированные экземпляры Frontend
  • Поддерживаемые экземпляры

Независимые от языка затраты:

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

Ответ 3

Вопрос в основном неактуальен.

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

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

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

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

  • Является ли ваше приложение вычислительно интенсивным? Java (JIT-compiled) и Go, вероятно, лучше, чем Python для математических операций.

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

Ответ 4

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

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

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

enter image description here

Ответ 5

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

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

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