Pull to refresh

Comments 74

Пробовал на java тестить? всё так же?)
Вот есть приложение на java
Объём данных по больше и скорость работы нормальная.
Там приводится тест Datastore и memcached.
Корень проблемы — в производительности системы хранения данных. От языка это сильно не зависит.
А по сути — нет, не пробовал. Основная платформа все-таки Python, и сам гугл её использует.
От языка вообще не зависит хранилище. Основной платформы нет, есть 2 среды исполнения. Все «оборачивается» в protobuf и проходит через rpc, читайте ниже.
UFO just landed and posted this here
Готово, картинка на главной ;-) :-)
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
GAE и AWS не одно и тоже.
AWS «продвинутый» хостинг.
GAE же дает среду, так же как если бы вы писали приложения под Win API.
Концептуально архитекторы GAE заглянули дальше чем AWS.
Да, теперь хотелось бы услышать результаты подобной проверки по амазонскому сервису.
помоему GAE рано еще так тестить:
1) клиентов у GAE на порядок меньче чем у амазона
2) амазон все таки предоставляет виртуальные машины, а не среду выполнения
Подтверждаю. GAE, — даже без обращений к базам, без авторизаций, сессий и прочего, — просто по HTTP отвечает не всегда; и часто — с очень большими задержками. В AJAX-приложениях надо обязательно учитывать таймауты и обязательно выдавать хорошие сообщения при протормозах (т.е. не просто отваливаться, а писать «подождите», «повторите»,...), иначе сервис выглядит как полное глюкалово. Такой проблемы с тормозами, как в GAE, я не видел нигде.
На форум им писать не пробывали? Они обычно отвечают в течении всего их рабочего дня, постоянно мониторят. Надо описать проблемму и сказать app-id. У вас включена оплата на приложении?
Есть подозрения, что как и у многих хостинг компаний в европе (и уже пошла практика у нас), вначале (бесплатно) дают мелкие возможности и ресурсы на опробирование, а уж надо серьезно позвольте переходить на тариф покрупнее и платить поболее…

«Ну а классические LAMP Web-приложения, которые не показывают 100 запросов в секунду должны отправляться прямиком на свалку :crazy:»
Не скромный вопрос, но что такое классические LAMP веб-приложения?
Вероятно имеется ввиду аббревиатура характеризующая обычное окружение — LAMP = Linux Apache MySQL PHP
Наверное, автор имел в виду, что такое классическое веб-приложение под LAMP?
Что — так? Так что такое классическое веб-приложение, которое должно легко держать 10 млн хитов на LAMP? Мне тоже интересно.
Я хотел сказать, автор комментария имел в виду. Не автор поста.
Ну вообще не забывайте, что проект в стадии pre-release, и не было пока сообщений, что он вышел из этого статуса. Во вторых — 22 сентября они «меняют» хранилище на улучшенное, так что посмотрим на его работу.

Далее, мемкеш тормозной, не потому что он забит, а потому что все обращения к любым сервисам проходят через rpc, читайте доки (сегодня средняя скорость чтения ~10мс на ключ. Все операции последовательны). Так же это относится к локальному sdk, текущие реализации (а гугл пока свой rpc-сервер не собираеся открывать) не позволяют сделать его быстрым. Хотите скорости на локали, отправьте им быструю версию, они примут.

По поводу масштабируемости — было неоднократно замечено, что быстро маштабировать gae начинает при включенной оплате. Что логично. У меня нагрузка на приложении легко возрастала в 10-15 раз, все было ок.

Ну и в завершении, AppEngine надо уметь готовить. Есть jaiku.com, google modertor (который висит на сайте белого дома, если не ошибаюсь) и т.п высоконагруженные приложения. Работают они хорошо, без видимых ошибок.
1. Будем верить и недеяться
2. На мой взгляд 10мс на memcached — это никогда не будет приемлимо. И наличие rpc не значит, что нельзя было иметь 1мс.
3.
4. С этим не поспоришь. Подходящие приложения написать хорошо можно.
Ну считайте что это не memcached, а ничего не гарантируеще хранилилище типа key-value… Наличие прослойки в виде rpc и говорит о том, что хотелось бы, но 5мс предел, насколько я знаю… плюс само обращение. А на кой вам больше если не секрет? 1000 запросов в мемкеш на один веб-запрос — это неграмотно спроектированное приложение. А так из разных запущенных инстансов AppEngine, мемкеш дергается фактически параллельно. 8 мс — это на последовательные запросы из одного приложения. Но из-за локов в транзакционных записях могут быть проблеммы со скоростью, тут архитектурой заниматься надо.
Любые пределы — в голове. Можно и 0.5мс иметь на запрос, можно и 0.05. :-)
1000 запросов не нужно, а вот 20 — это похоже на правду.

Пределы в архитектуре их rpc, насколько я понял из разговоров с разработчиками. Они бы и сами рады наверное, да никак.
А даже 20 это имхо многовато. В среднем 10, т.е 80-100мс, что допустимо для любого веб-приложения.
UFO just landed and posted this here
Ну кратко есть тут. Чтиво ровно на 5 мин.
UFO just landed and posted this here
Меня в нем привлекает архитектура гугли и де-юро масштабируемость. Это в краце. Полностью меня в нем привлекает все то, что написанно по ссылке, которую дал выше. + там не описанны TaskQueues и XMPP. Полностью все есть в англ. версии.
Если в русском тексте встречаешь фразу «полное дерьмо» сразу же понятно, что это перевод ;)
Вы будете смеяться, но таки да :-)
Сначала я написал английскую версию :-D
попробуйте MS Azure
тормозов никаких не замечено
всё просто «летает».
парни, за что минусуем? Пробовали, и тормозит? Тогда расскажите пожалуйста!
кстати. сама МС выпустила кучи инструкций о том, как ваше любимое (или не любимое) приложение на РНР запускать на Azure с минимумом модификаций.
для поклонников питона есть IronPython, который тоже отлично работает на Azure
Включали ли Вы биллинг?
Сам не делал сравнений, но точно читал статью с подобными сравнениями, где автор с радостью обнаружил, что и лимиты на сервисы и скорость сильно поднимаются при включённом биллинге(при этом это не значит, что нужно выйти за пределы бесплатных параметров)
Насчет исключения про слишком много запросов к одной сущности: в документации про это явно написано, так что исключение не такое уж и неожиданное.
К слову, была же хорошая статья, как гаджет для Евровидения делали на GAE. И там хорошо описано, для чего GAE подходит, а для чего — нет.
Но четко ясно — GAE не универсальное средство и подходит далеко не для всего.
Нужно знать, что можно делать, а что нет. Нужно знать множество мелочей, которые иногда сильно влияют на производительность.
В догонку к urlfetch — сделал для себя habrahabr-lite для того чтобы смотреть на мобиле. toster1976.appspot.com (не реклама). Если бы сейчас переделывал, то сделал бы выкачивание url по крону и кэширование. Когда делал часть запросов не отрабатывала и глючила авторизация, по этому забил на все это.
Писал на основе GAE Java Web-приложение. Не дождался поддержки миграций для разрабатываемых приложений с версии на версию, а без них трудно соблюсти полный цикл разработки и поддержки продукта. Ушёл с сервиса.
статику с него отдавать — как раз те 10М запросов получаться. Только статику лучше с code.google.com отдавать :)
А я по совету webo.in/articles/all/2009/08-google-cdn-in-minutes/ разместил статику (600 кб) на google appengine.
Движок сайта (самописный на django) и база mysql на firstvds под apache.
Время загрузки по тестам на webo.in сократилось в 1,8 раза
UFO just landed and posted this here
UFO just landed and posted this here
Google использует стратегию «ковровой бомбардировки» даже если 2 сервиса из 20 будут успешными, то при таком объеме он итак забирает значимую долю рынка.
Эффективность хостинга мощностей наиболее высока на больших ресурсах и за адекватные деньги, например cdn-хостинг Akamai.
Минус — отсутствие QoS. Работали ли Вы с локальной базой данных где каждый 1000 запрос отваливался, а каждый 10000?
Ого! Может статью напишете о его разработке?
Обязательно. Планировал в ближайшее время написать о подводных камнях с которыми столкнулся при разработке, но к сожалению пока нет на это времени. Но раз тема поднялась не мог не упомянуть о нашем реально существующем и работающем проекте на GAE.
По просьбам трудящихся небольшая заметка в личном блоге.
Появится карма — перенесу в блог GAE.
Будут вопросы, напишу более подробно.
Магазин писался с «нуля» или в GAE были портированы наработки?
Если использовались готовые наработки, то какие «грабли» были при портировании в GAE?
Писался с нуля.
На текущий момент есть проблемы с загрузкой/выгрузкой большого количества данных. На данный момент использую CSV для загрузки обновлений (цены, товары, наличие). При большом объеме данных превышается тайм-аут 30 сек на выполнение. Кроме этого в GAE ограничение на 30 запросов на запись (put). Соответственно обновлять больше 30 товаров за один проход не получается. Этот момент можно оптимизировать и обновлять данные не поштучно, а сразу пачками т.к. в GAE запись в хранилище может производится целыми массивами.
Выгрузка данных для Яндекс.Маркета занимает почти 10 секунд (200 товаров), 90% времени это генерация HTML.

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

Тоже самое касается выгрузки. Яндекс сам раз в час забирает свежий прайс, он не знает что такое коммандная строка (только через нее работает массовая загрузка/выгрузка) и ему нужно отдавать данные в XML и раздельно отрабатывать его GET и HEAD запросы.
TaskQueue вам в помощь. Я думаю к следующему релизу он выйдет из labs, ну а пока можно пользоваться и так.
Точнее Cron.
TaskQueue немного другие задачи решает. А кроме этого лимиты в 30 сек. и на get()/put() все равно остаются.
TaskQueue, генерация контента частями, кеширование. Это про Я.Маркет.
А про выгрузку-загрузку — ну я бы все же на bulk_uploader посмотрел. Готовое мнгопоточное решение запихивания данных в базу.
Сделайте отдельную «промежуточную таблицу», куда вы будете лоадером данные заливать, а потом уже через веб-интерфейс эти данные обрабатывать, «подтверждать» и чего там вам нужно. Или, опять же, Cron, да.
Вполне себе можно по расписанию из определенного места.

В решении таких задач в GAE приходится крутиться и придумывать всякие хитрые штуки :) Ну и главное — параллелить и разбивать задачу на кучу мелких подзадач, чтобы не вылезти за лимиты.
Скоро еще MapReduce обещают. Вернее эфективное хранилище для reduce(), map() то по сути готов в тасках.
Не, крон то ясно для подгоовки периодики. Я для обновления имел ввиду. Ну и + батчи. Я предпочитаю у себя если индексов много и обьект большой, не более 10 в батче и распределять по таскам, типа лучше меньше и часто, и в батчах.
И последний вопрос. После разработки на GAE, променяли бы вы его на обычный платный хостинг?
Преимуществ у GAE на данный момент все-таки больше чем недостатков. На платном хостинге на мой взгляд имеет смысл делать проект который нельзя сделать на GAE.
Самое главное для меня — это отсутствие головной боли с покупкой/настройкой/поддержкой серверов.
Естественно речь о проектах требующих не меньше VPS.
Еще преимущество — надежность.
Все-таки кластер из кучи серверов в нескольких ДЦ — это очень серьезно. Я считаю, что это надежно.
VPS/дедик/колок может упасть — и это жопа :) Мало ли что с сервером могут сделать. Если конкуренты злые, то могут и украсть, и изъять…
Ну или надо несколько серверов для обеспечения надежности — а это уже дорого.

К слову, это характеристика клауда, а не только GAE.
Интересно, что у вас favicon дефолтный :)
Спасибо за интересную статью! Будет интересно почитать о тестировании Amazon Web Services в вашем исполнении :)
По поводу своего домена: покупаете на стороне домен ВашДомен, регистрируете и устанавливаете для него Гугл Почту, после этого прямо в почте можно добавить ваше приложение из GAE и присвоить ему www.ВашДомен. А для просто www.ВашДомен делаете редирект 301 на ВашДомен.
Паривно конечно, но работает, если не охота сидеть на доменах *.appspot.com

У меня чистая статика тут www.roadslot.com. Действительно удобно, если уже знаком с технологией.
Кстати, уже существуют и первые социальные сети UGC-типа, вполне успешно работающие на GAE.

Реальный работающий пример: enetri.com, украинский аналог Хабра.
Работает уже почти полгода, полет — нормальный, впечатления — положительные :)
Ого классная статья, еще бы про windows azure узнать
Only those users with full accounts are able to leave comments. Log in, please.

Articles