Pull to refresh

Comments 84

"$0.10 per CPU core hour. This covers the actual CPU time an application uses to process a given request, as well as the CPU used for any Datastore usage."
Думаю тут не корректно сравнение с AWS'овским часом.
Ага, точно. Сейчас исправлю. Для полноты картины, как считается процессорное время, следует добавить еще одну цитату из доков:
«CPU time is reported in „seconds,“ which is equivalent to the number of CPU cycles that can be performed by a 1.2 GHz Intel x86 processor in that amount of time. The actual number of CPU cycles spent varies greatly depending on conditions internal to App Engine, so this number is adjusted for reporting purposes using this processor as a reference measurement.»
Интересно будет посмотреть на первых пользователей услуг.
Ну я пользователь один из первых

Регулирование бюджета простейшее, с распределением дневного в процентах по 5 вышеперечисленным в статье позициям. Оплата происходит еженедельно, с «предоплатой» в 7 дней. Ребилл автоматический. Подробнее об системе оплаты в доках GAE

Система оплаты одна — google checkout, соответственно надо иметь кредитку, с которой спишут дополнительно 1 доллар при 1-й транзакции с этой карты через гугл чекаут

Скрины приложить не могу, кармы говорят нету
Скрины приложить не могу, кармы говорят нету

Попобуйте сейчас.
Всем спасибо за карму, вот скрин, как раз залил на чье-то gae-приложение :)
Прошу прощения за вопросы, ответы на которые скорее всего есть в документации, но тем не менее — вы с этим уже поработали и у вас есть реальный опыт.

Вопросы такие:

Что происходит с приложением в случае превышения дневной квоты на что-нибудь? Оно просто перестаёт обслуживаться, или с вас списываются дополнительные деньги за превышение, или это настраивается?

Что происходит с вашими деньгами в случае невыбирания дневной квоты — они тратятся или нет? Т.е. вы платите за квоту или за реальное использование ресурсов?
Значит так, есть 2 вида квот — фиксированные и увеличенные. Увеличинными могут быть 5 описанных в статье, остальные увеличиваются автоматом при подключении биллинга. Там таблички, разберетесь.

1. Получаем apiproxy_errors.OverQuotaError.
Причем если вы выставили на цпу 70% при дневном бюджете в $1, то откустить 30 центов у остальных позиций нельзя, OverQuota.

2. Деньги списываются естественно за реальное использование ресурсов. Но есть одно но. Мин. дневной бюджет — $1, недельная квота списывается автоматом, зачисляется на балланс. Но если вы ее не выбираете, 7 следующих баксов списываются автоматом через g.chechout, там это подписка. Причем я так понял, что если нам на баллансе хватает денег, то при отмене подписки (читай отмене биллинга) у нас есть 30 дней пока не упадут фиксированные квоты обратно до фришного состояния. Вообщем мутно… Но если билл отменился, то деньги остаются на баллансе приложения, и потом при возобновлении платежа все остается на своих местах. Так что у меня не то что реальный опыт — так, со среды балуюсь, при этом забил специально старую виртуалку с остатком на счету $11, реально посмотеть как отреагирует на отсутствие денег.

А так многие вопросы есть в faq
Мне кажется за USD 365+ программер сможет кастомизировать уже имеющийся (положим, купленный) модуль или аппликейшн. А следующий год — бесплатно :)

Ну естественно, при этом у меня за USD 365 есть возможность дописать нужный функционал, а в случае с GoogleApps — нет.

Хотя есть бааа-льшой "+": сотни тысяч инсталляций, так что порядочные девеловперы будут иметь стимул хорошо писать код.

а во сколько примерно тебе это в месяц обходиться?
и насколько прожорливе проэкты у тя на нем висят?
На данный момент 1$ бюджета в день мне хватает за глаза

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

учитывая 365х1 примерно тоже самое + доп ресурсы мона продавать
Не знаю что ответить… :) Я занимаюсь программированием своих идей, и мне волшебно подходит cloud computing. Я не хочу думать о железе, администрировании, маштабируемости; мне нравится аппаратные и программные решения гугли.
Ну и правильно — для людей с потребностями «Я занимаюсь программированием своих идей» оно и создавалось.
Если
1) у вас есть место, куда можно поставить такую машинку;
2) вас не сильно волнует время простоя из-за проблем с интернетом, электричеством, whatever в этом месте;
3) там дешёвый быстрый канал в интернет, либо вам это не важно;
4) вы собираетесь сами настраивать сервер и решать проблемы с конфигурацией в случае их возникновения (и вас не сильно волнует потраченное на это время);
5) вы собираетесь сами создавать систему резервного копирования, либо вам не важна потеря данных;
6) вы точно уверены, что вашему проекту всегда будет хватать одного сервера;
— то да, вам совершенно не нужен GAE :-)
1) да
2) пока да, потом перееду на colocation
3) да, пока хватает
4) да, я обожаю это делать
5) пока надеюсь на RAID5
6) когда проект перерастет эту машину значит он будет иметь и финансовые возможности поселиться еще где нить

но с GAE, пока он еще бесплатен, думаю что выкрою пару дней чтобы поиграться
но скорее из-за того чтобы понять принципы которые заложил гуг в данную масштабируемую систему
Хм. Не знал про такое. Надо будет изучить.
хм… мне все таки очень интересно приблизительную формулу расчета получить… понятное дело, что сложно, или хотя бы приблизительную стоимость :)
Что значит формула расчета? Все зависит от вашего приложения, какие ресурсы ему надо.

В процентах дневной бюджет распределяется для «standard» так —:
CPU Time 60%
Bandwidth Out 16%
Bandwidth In 4%
Stored Data 20%
Recipients Emailed 0%

Естественно можете менять все параметры как душе угодно. Мне например нужны мощности только bigtable — забиваю например при дневном бюджете в 2$:
CPU Time 70%
Stored Data 30%

получаю:
Resource Budget Unit Cost Paid Quota Free Quota Total Daily Quota
CPU Time 60% $0.10 11.99 46.30 58.29 hours
Stored 30% $0.005 120.00 1.00 121.00 GBytes*
* Your application's maximum data storage capacity.

Остальные «халявные» позиции не выписываю

Ну вот как-то так
Спасибо!
Вопросов больше нет :)
сколько наиспользовал — столько и оплачиваешь
Кстати, небольшое замечание автору:
Вы пишите — "… особенно если вы… пишете на питоне" — это единственный поддерживаемый язык, 2-й будет скорее всего не раньше апреля.
И что-то 5 точка мне подсказывает что это будет не java а perl, хотя очень хочется чтобы я ошибался.
Да, я в курсе. Хотел сказать, что для питонистов появилась серьезная альтернатива AWS'у. Кстати, сами они говорят, что это будет java.
Это я читал, но это типа утка. Хотя гугловцы не подтвердили, но и не опровергли. Я посему и сказал, что очень хочу ошибиться. Посмотрим, понадеемся, хотя питон меня полностью устроил — а до этого ни разу на нем не писал; изучал параллельно gae
UFO just landed and posted this here
а есть у GAE прямая поддержка Django?
UFO just landed and posted this here
ну я бы не сказал, что это мегасущественно, учитывая возможность невозбранно использовать memcache
а хитрые отчеты можно и «вручную» строить
UFO just landed and posted this here
ах, блин, да, ограничение на 1000 это…
ну узнаем общее кол-во, выбираем несколько раз и складываем =\ криво, но вроде бы терпимо. если будут хитрые формулы, придется конечно велосипедировать, но разве не стоит ли оно того? конечно не на всех задачах, но на многих — стоит

и, кстати, щас пришла мысль — а вы уверены, что такой запрос не сработает на > 1000? речь ведь идет о fetch, а не о самом запросе. fetch-то в данном случае вернет 1 ячейку )
я еще не щупал gae, но что-то мне кажется, что такое должно работать, надо обязательно проверить
UFO just landed and posted this here
Для этой задачи нужно делать так

То есть при разработке приложение нужно отказаться от всех идеологий присущих реляционным базам данных. Это сложно, привыкал достаточно долго.
UFO just landed and posted this here
Только что проверил — действительно возвращается не больше 1000
Есть, но в SDK включена версия 0.96. Советую использовать app_engine_patch для работы с django в gae. В версии 1.0 (совсем недавно вышла) включена поддержка приложений, включая джанговскую админку.
UFO just landed and posted this here
Оно никогда не будет снято. Этим правилом (и некоторыми другими описанными тут) пользуются и сами гугловцы при разработке своих приложений. Это ограничение bigtable.
UFO just landed and posted this here
А вы никогда не задумывались почему гугль возвращает в выдаче не более 1000 результатов? :)

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

Просто в gae мы пользуемся всем тем, что и гугловцы (и сервера те же, рядом с нашим приложением — физически на сервере — может жить тот же gmail)
UFO just landed and posted this here
Сделали ровно для того, чтобы приложение на локали было идентично приложению на продакшене, а то по глупости некоторые писали на локали, заливали — а не работало, ексепн вылезал.

Я ж говорю (я не работаю в гугле инженером bigtable), скорее всего этот параметр жестко вкомпилен в bigtable. А сам bigtable (какие-то его части?) стоит скорее всего на ВСЕХ серверах гугли (ну или на большей части точно, ибо все внешние файлы — текст, фото, видео — хранятся в bigtable, он для этого и был сделан совместно с gfs).

А почему 1000 — причины попробывал обосновать выше (так исторически получилось). И еще — представьте ситуацию — все 1000 обьектов разбросаны по 1000 серверам из кластера, мин. кусок из gfs — 64 метра, значит сделав выборку, имеем дело с обработкой 64 гигов, такая арифметика :)
Я вот прочитал начало справочного центра этого сервиса, правильно ли я понимаю, что это не виртуальная машина (как на AWS), а чисто хостинг для проектов на питоне?
Да. И даже более того — это не просто хостинг на питоне, а хостинг именно на GAE. Там есть вещи, из-за которых переезжать потом в другое место будет очень проблематично (пресловутый BigTable). Но при этом этот хостинг очень масштабируемый — и очень гибко масштабируемый. Поэтому напрямую сравнивать с Амазоном нельзя — Амазон более универсальный, но в итоге получается дороже (процессор тратится не только на ответы пользователям, но и на работу ОС, на работу в то время, когда нет запросов и прочее). Да и BigTable, несмотря на свою несовместимость с остальныи базами (или благодаря ей? ;-) ), штука довольно привлекательная из-за своей масштабируемости и отказоустойчивости. Так что свои плюсы и минусы есть и у AWS и у GAE.
> Там есть вещи, из-за которых переезжать потом в другое место будет очень проблематично (пресловутый BigTable)
В следующих версиях app-engine-patch обещают более полную поддержку джанго, в том числе и моделей. Ждём и надеемся, возможно, Ваши слова наконец перестанут быть правдой :)
А более полная поддержка моделей будет когда перелопатят django models, и версия 1.0.2 будет deprecated (да и 1.1), ибо транзакции тут краеугольный камень (да и ограничения bigtable)

А перехать потом с бигтабла будет достачно просто на тот же mysql с помощью скоро ожидаемого «Datastore import and export utility for large datasets». Но кросс-решения не будет точно, у реляционных бд и бигтабла слишком разная философия, имхо
Минус один — мне нужен полноценный сервер, куда я могу установить нужный мне софт. Так что, к сожалению, не подходит.
(пожимая плечами) Не подходит — не используйте, в чём проблема? Никто, в общем-то, и не обещал Универсального Решения Для Всего На Свете.
Знаете, после почти года развлечения с gae (пока квоты неделю назад не ввели — развлеченя закончились, начались серьезные проекты) я не знаю, что нельзя на нем написать под веб :) Чего действительно нехватает — но уже есть частично в sdk и скоро будет на продакшене — это:
Support for scheduled tasks
Task queues for performing background processing

Для этих задач пока пользуюсь внешними вызовами — несколько неудобно.
> квоты для него будут снижены в течение 90 дней

Э, я по rss читал, но как-то в английском варианте не заметил этого момента. Вы не в курсе, насколько именно они будут снижены в каждой из позиций?
Из их блога: «We believe these new levels will continue to support a reasonably efficient application serving around 5 million page views per month, completely free.»
Точные цифры они еще не назвали.
Точные цифири названы тут

Точные цифири названы тут

CPU Time: 6.5 hours of CPU time per day
Bandwidth: 1 Gigabyte of data transferred in and out of the application per day
Stored Data & Email Recipients: these quotas will remain unchanged.
А вообще, кто хочет разобраться с bigtable (в реалиях gae), то читайте:

1. Datastore API (работа с хранилищем) — официальная дока
2. Under the covers of the App Engine Datastore — презентация инженера bigtable

Читать это надо так — быстро просмотреть в (2) что где располагается, и при прочтении (1) обращаться к (2). Сразу наглядно понятно как используются индексы, паренты, транзакции, группы обьектов и т.п

+ есть статьи частично переведенные тут
UFO just landed and posted this here
И на сколько процентов по цпу выгоднее?

И если можно, коротенький пример в студию (если можно — от описания модели, к работе с ней) — а то никогда не работал напрямую, а самому разбираться некогда. Заранее спасибо
UFO just landed and posted this here
UFO just landed and posted this here
а через db.put(save) не пробовали?
Ну так оно там так и делается:
entities = [model._populate_internal_entity() for model in models]
keys = datastore.Put(entities)

Что-то 2-й раз за сегодня часть коммента сьедается, браузер — опера
Вообщем пока недоказано выгода использования api.datastore. Попробуйте через db.put(), посмотрите в админке продакшена, сколько цпу код сьел до и после. Насколько я знаю, сам гвидо писал datastore api, и думаю профайлил это дело не раз. А мы с вами вместе взятые точно пишем хуже его :)
UFO just landed and posted this here
Причем что интересно — GAE (и соответственно пользовательские программы) разнесено географически в трех датацентрах.
Два в США, на восточном побережье (в южной каролине) и на западном(в калифорнии). И еще в датацентре на тайване.
А откуда информация?
из своего проекта ;)
А стата по пользователям есть?

Если у меня верная инфа, гае уже разнесен по абсолютно всем ДЦ гугли, ибо это уменьшает время доступа к приложению -> разгружает архитектуру. ghs следит за этим. Если из пользователей много русских, задействуются через какое-то время русские сервера (если такие есть — если нет, ближайшие по географии, нагрузке, етц)
про свой проект я имел ввиду не на GAE проект, а WIPmania.com
насколько я знаю, в европейских датацентрах GAE не запущен, по крайней мере мне не известен ни один проект, который бы запускался, например, в Лондоне или Франкфурте.
Всё только в вышеназванных четырех DC.
Проверьте свои проекты, скорее всего они под адресами 74.125.47.141 или 74.125.93.141, а это восток США
Забыл упомянуть четвертый датацентр, где работает GAE — это в Японии
За GAE будущее — полная абстракция от железа и всяческих механизмов, интеграция web-приложений возможна на гораздо более высоком уровне — не нужно обмениваться XML-ями, можно взаимодействовать через классы(!), причем если развить мысль приложениям могут быть расположены на разных взаимодействующих GAE-подобных системах.
Большой респект гуглу, это одна из немногих вещей которые могут принципиально изменить веб через пару лет! :)
Внутри гугл обменивается через protocol buffer, в gae аналогично взаимодействие с services api
Мне показалось, что protocol buffer «построен» на основе классов… хотя могу ошибаться, с GAE ещё не работал, жду когда гугл закончит тестирование, судя по данному посту уже скоро )
Дык хмл тоже можно десериализовать в класс, проблем нет

Дело в том что класс — штука абстрактная, передается он между чем нибудь в сериализованном виде. XML — текстовый, PB — бинарный, со всеми вытекающими, вот и вся разница
бинарный — получается мы передаем орудие действия, текстовый — лиш указания к нему
мне кажется разница принципиальна
Мы передаем биты данных, не более :) Первый нельзя прочитать глазами без спец. программ, второй — можно. Все равно любые сериализованные данные проходят десериализацию (xml-parser/binary decoder/etc).
А вообще хабрите :), нахабрил 1, 2 с почти на первый взгляд холиваром в комментах, что круче, бинарная или текстовая сериализация/десериализация

Гугл выбрал для внутренних нужд бинарную.
Будущее за нормальными облаками, типа амазоновского.
Да, и кстати, тем кто хочет заняться этой платформой — гугл накладывает некоторые ограничения на контент — посему не ошибитесь в выборе, бан будет достаточно быстр — проверял

— Контент, который нарушает права третьих лиц в соответствии с нормами юридического права;
— Порнографическое или непристойное содержание;
— Содержание, связанное с разжиганием ненависти или насилия;
— Пропаганда расовой или этнической нетерпимости;
— Контент, относящийся к взлому компьютерных систем;
— Азартные игры;
— Другая противоправная деятельность, включающая в себя незаконный экспорт контролируемых веществ или программного обеспечения;
— Распространение наркотиков;
— Фишинг;
— Вредоносное содержание;
— Страницы, полностью состоящие из рекламы;
— Другие материалы, продукты и сервисы, которые нарушают положения гражданского или уголовного права или права и свободы третьих лиц.

Так что не потратьте время впустую на проект.
Ну то что дорвеи и порно, рулетки и им подобное гуано будет вне закона никто не сомневался. Но этот контингент думаю сильно не расстроится, для их деятельности достаточно существует платформ.

Кстати ограничения областей никогда не скрывалось и в лицензионном соглашении есть слова

3. Service Policies and Privacy
3.1. You agree to comply with the Google App Engine Program Policies included available at code.google.com/appengine/program_policies.html (or such URL as Google may provide) (the «Program Policies») which is incorporated herein by this reference and which may be updated from time to time.

Если вы этого внимательно не читали то тут только ваша вина.
Я читал это в первый день с выпуском платформы. Я проверил время сноса. Интересно мне было как-то поздним скучным вечером :)
Ограничение для безплатного даже увеличили раньше было 3 млн. показов, я тут подсчитал это почти два показа в секунду. Конечно тут будут вариации в зависимости от приложения и насколько оно будет грузить процесор больше лимита. Но лично мне для планируемого хомяка где больше 100 посетителей в день не предвидится больше и не надо.
У меня есть достаточный для моих нужд server-side на Python, да не все хотелки есть, но ситуация с каждой версией улучшается, да и это безплатно. Все мои затраты это оплата домена на год, почта, блог, вики, jabber, и даже получается хостинг безплатно. Конечно это решение не для всех. Есть люди для которых GAE засложен им легче заплатить за хостинг на worldpress например.

Кстати некоторое время назад в блоге GAE промелькнула ссылка на app-engine-site-creator, несложная CMS под GAE к которой присматриваюсь.
Вот интересно, возможно ли в GAE реализовать сокет-сервер для чтения tcp-пакетов по одному из портов, предусмотрены вобще механизмы работы с сокетами?
An App Engine application cannot:

* open a socket or access another host directly. An application can use the App Engine URL fetch service to make HTTP and HTTPS requests to other hosts on ports 80 and 443, respectively.
Sign up to leave a comment.

Articles