Comments 74
Пробовал на java тестить? всё так же?)
Вот есть приложение на java
Объём данных по больше и скорость работы нормальная.
Там приводится тест Datastore и memcached.
Объём данных по больше и скорость работы нормальная.
Там приводится тест Datastore и memcached.
Корень проблемы — в производительности системы хранения данных. От языка это сильно не зависит.
А по сути — нет, не пробовал. Основная платформа все-таки Python, и сам гугл её использует.
А по сути — нет, не пробовал. Основная платформа все-таки Python, и сам гугл её использует.
UFO just landed and posted this here
UFO just landed and posted this here
Да, теперь хотелось бы услышать результаты подобной проверки по амазонскому сервису.
помоему GAE рано еще так тестить:
1) клиентов у GAE на порядок меньче чем у амазона
2) амазон все таки предоставляет виртуальные машины, а не среду выполнения
1) клиентов у GAE на порядок меньче чем у амазона
2) амазон все таки предоставляет виртуальные машины, а не среду выполнения
Подтверждаю. GAE, — даже без обращений к базам, без авторизаций, сессий и прочего, — просто по HTTP отвечает не всегда; и часто — с очень большими задержками. В AJAX-приложениях надо обязательно учитывать таймауты и обязательно выдавать хорошие сообщения при протормозах (т.е. не просто отваливаться, а писать «подождите», «повторите»,...), иначе сервис выглядит как полное глюкалово. Такой проблемы с тормозами, как в GAE, я не видел нигде.
Есть подозрения, что как и у многих хостинг компаний в европе (и уже пошла практика у нас), вначале (бесплатно) дают мелкие возможности и ресурсы на опробирование, а уж надо серьезно позвольте переходить на тариф покрупнее и платить поболее…
«Ну а классические LAMP Web-приложения, которые не показывают 100 запросов в секунду должны отправляться прямиком на свалку :crazy:»
Не скромный вопрос, но что такое классические LAMP веб-приложения?
«Ну а классические LAMP Web-приложения, которые не показывают 100 запросов в секунду должны отправляться прямиком на свалку :crazy:»
Не скромный вопрос, но что такое классические LAMP веб-приложения?
Ну вообще не забывайте, что проект в стадии pre-release, и не было пока сообщений, что он вышел из этого статуса. Во вторых — 22 сентября они «меняют» хранилище на улучшенное, так что посмотрим на его работу.
Далее, мемкеш тормозной, не потому что он забит, а потому что все обращения к любым сервисам проходят через rpc, читайте доки (сегодня средняя скорость чтения ~10мс на ключ. Все операции последовательны). Так же это относится к локальному sdk, текущие реализации (а гугл пока свой rpc-сервер не собираеся открывать) не позволяют сделать его быстрым. Хотите скорости на локали, отправьте им быструю версию, они примут.
По поводу масштабируемости — было неоднократно замечено, что быстро маштабировать gae начинает при включенной оплате. Что логично. У меня нагрузка на приложении легко возрастала в 10-15 раз, все было ок.
Ну и в завершении, AppEngine надо уметь готовить. Есть jaiku.com, google modertor (который висит на сайте белого дома, если не ошибаюсь) и т.п высоконагруженные приложения. Работают они хорошо, без видимых ошибок.
Далее, мемкеш тормозной, не потому что он забит, а потому что все обращения к любым сервисам проходят через rpc, читайте доки (сегодня средняя скорость чтения ~10мс на ключ. Все операции последовательны). Так же это относится к локальному sdk, текущие реализации (а гугл пока свой rpc-сервер не собираеся открывать) не позволяют сделать его быстрым. Хотите скорости на локали, отправьте им быструю версию, они примут.
По поводу масштабируемости — было неоднократно замечено, что быстро маштабировать gae начинает при включенной оплате. Что логично. У меня нагрузка на приложении легко возрастала в 10-15 раз, все было ок.
Ну и в завершении, AppEngine надо уметь готовить. Есть jaiku.com, google modertor (который висит на сайте белого дома, если не ошибаюсь) и т.п высоконагруженные приложения. Работают они хорошо, без видимых ошибок.
1. Будем верить и недеяться
2. На мой взгляд 10мс на memcached — это никогда не будет приемлимо. И наличие rpc не значит, что нельзя было иметь 1мс.
3.
4. С этим не поспоришь. Подходящие приложения написать хорошо можно.
2. На мой взгляд 10мс на memcached — это никогда не будет приемлимо. И наличие rpc не значит, что нельзя было иметь 1мс.
3.
4. С этим не поспоришь. Подходящие приложения написать хорошо можно.
Ну считайте что это не memcached, а ничего не гарантируеще хранилилище типа key-value… Наличие прослойки в виде rpc и говорит о том, что хотелось бы, но 5мс предел, насколько я знаю… плюс само обращение. А на кой вам больше если не секрет? 1000 запросов в мемкеш на один веб-запрос — это неграмотно спроектированное приложение. А так из разных запущенных инстансов AppEngine, мемкеш дергается фактически параллельно. 8 мс — это на последовательные запросы из одного приложения. Но из-за локов в транзакционных записях могут быть проблеммы со скоростью, тут архитектурой заниматься надо.
UFO just landed and posted this here
Ну кратко есть тут. Чтиво ровно на 5 мин.
Если в русском тексте встречаешь фразу «полное дерьмо» сразу же понятно, что это перевод ;)
попробуйте MS Azure
тормозов никаких не замечено
всё просто «летает».
тормозов никаких не замечено
всё просто «летает».
Включали ли Вы биллинг?
Сам не делал сравнений, но точно читал статью с подобными сравнениями, где автор с радостью обнаружил, что и лимиты на сервисы и скорость сильно поднимаются при включённом биллинге(при этом это не значит, что нужно выйти за пределы бесплатных параметров)
Сам не делал сравнений, но точно читал статью с подобными сравнениями, где автор с радостью обнаружил, что и лимиты на сервисы и скорость сильно поднимаются при включённом биллинге(при этом это не значит, что нужно выйти за пределы бесплатных параметров)
Насчет исключения про слишком много запросов к одной сущности: в документации про это явно написано, так что исключение не такое уж и неожиданное.
К слову, была же хорошая статья, как гаджет для Евровидения делали на GAE. И там хорошо описано, для чего GAE подходит, а для чего — нет.
Но четко ясно — GAE не универсальное средство и подходит далеко не для всего.
Нужно знать, что можно делать, а что нет. Нужно знать множество мелочей, которые иногда сильно влияют на производительность.
Но четко ясно — GAE не универсальное средство и подходит далеко не для всего.
Нужно знать, что можно делать, а что нет. Нужно знать множество мелочей, которые иногда сильно влияют на производительность.
По поводу URLFetch это правда.
Я тут баловался с GWT+GAE вот что получилось eventstimeline.appspot.com/
Я тут баловался с GWT+GAE вот что получилось eventstimeline.appspot.com/
В догонку к 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 раза
Движок сайта (самописный на django) и база mysql на firstvds под apache.
Время загрузки по тестам на webo.in сократилось в 1,8 раза
UFO just landed and posted this here
Google использует стратегию «ковровой бомбардировки» даже если 2 сервиса из 20 будут успешными, то при таком объеме он итак забирает значимую долю рынка.
Эффективность хостинга мощностей наиболее высока на больших ресурсах и за адекватные деньги, например cdn-хостинг Akamai.
Минус — отсутствие QoS. Работали ли Вы с локальной базой данных где каждый 1000 запрос отваливался, а каждый 10000?
Эффективность хостинга мощностей наиболее высока на больших ресурсах и за адекватные деньги, например cdn-хостинг Akamai.
Минус — отсутствие QoS. Работали ли Вы с локальной базой данных где каждый 1000 запрос отваливался, а каждый 10000?
У нас работает интернет-магазин на GAE. В среднем 500-600 хитов в день. Использует 0,3-0,4 часа процессорного времени в сутки из 6,5 бесплатных.
axiomashop.appspot.com/
axiomashop.appspot.com/
Ого! Может статью напишете о его разработке?
Обязательно. Планировал в ближайшее время написать о подводных камнях с которыми столкнулся при разработке, но к сожалению пока нет на это времени. Но раз тема поднялась не мог не упомянуть о нашем реально существующем и работающем проекте на GAE.
По просьбам трудящихся небольшая заметка в личном блоге.
Появится карма — перенесу в блог GAE.
Будут вопросы, напишу более подробно.
Появится карма — перенесу в блог GAE.
Будут вопросы, напишу более подробно.
Магазин писался с «нуля» или в GAE были портированы наработки?
Если использовались готовые наработки, то какие «грабли» были при портировании в GAE?
Если использовались готовые наработки, то какие «грабли» были при портировании в GAE?
Писался с нуля.
На текущий момент есть проблемы с загрузкой/выгрузкой большого количества данных. На данный момент использую CSV для загрузки обновлений (цены, товары, наличие). При большом объеме данных превышается тайм-аут 30 сек на выполнение. Кроме этого в GAE ограничение на 30 запросов на запись (put). Соответственно обновлять больше 30 товаров за один проход не получается. Этот момент можно оптимизировать и обновлять данные не поштучно, а сразу пачками т.к. в GAE запись в хранилище может производится целыми массивами.
Выгрузка данных для Яндекс.Маркета занимает почти 10 секунд (200 товаров), 90% времени это генерация HTML.
Также не решил еще проблему с фильтрами и сортировками товаров по характеристикам. Т.к. БД не реляционная, привязать характеристики к товарам тяжело. Как вариант делать для каждого типа товара вручную в коде свой фиксированный набор характеристик, это возможно пока типов товаров не больше десятка.
На текущий момент есть проблемы с загрузкой/выгрузкой большого количества данных. На данный момент использую CSV для загрузки обновлений (цены, товары, наличие). При большом объеме данных превышается тайм-аут 30 сек на выполнение. Кроме этого в GAE ограничение на 30 запросов на запись (put). Соответственно обновлять больше 30 товаров за один проход не получается. Этот момент можно оптимизировать и обновлять данные не поштучно, а сразу пачками т.к. в GAE запись в хранилище может производится целыми массивами.
Выгрузка данных для Яндекс.Маркета занимает почти 10 секунд (200 товаров), 90% времени это генерация HTML.
Также не решил еще проблему с фильтрами и сортировками товаров по характеристикам. Т.к. БД не реляционная, привязать характеристики к товарам тяжело. Как вариант делать для каждого типа товара вручную в коде свой фиксированный набор характеристик, это возможно пока типов товаров не больше десятка.
bulk data uploader / downloader пробовали использовать?
code.google.com/appengine/docs/python/tools/uploadingdata.html
code.google.com/appengine/docs/python/tools/uploadingdata.html
Это подходит только для разовой выгрузки/загрузки.
Данные на сайт загружаются ежедневно, данные после загрузки должны обрабатываться и вносить изменения в существующие данные (проверять изменение цены/наличия и добавлять новый товар).
Кроме этого загружаться все должно само по расписанию из определенного места.
Тоже самое касается выгрузки. Яндекс сам раз в час забирает свежий прайс, он не знает что такое коммандная строка (только через нее работает массовая загрузка/выгрузка) и ему нужно отдавать данные в XML и раздельно отрабатывать его GET и HEAD запросы.
Данные на сайт загружаются ежедневно, данные после загрузки должны обрабатываться и вносить изменения в существующие данные (проверять изменение цены/наличия и добавлять новый товар).
Кроме этого загружаться все должно само по расписанию из определенного места.
Тоже самое касается выгрузки. Яндекс сам раз в час забирает свежий прайс, он не знает что такое коммандная строка (только через нее работает массовая загрузка/выгрузка) и ему нужно отдавать данные в XML и раздельно отрабатывать его GET и HEAD запросы.
TaskQueue вам в помощь. Я думаю к следующему релизу он выйдет из labs, ну а пока можно пользоваться и так.
Точнее Cron.
TaskQueue немного другие задачи решает. А кроме этого лимиты в 30 сек. и на get()/put() все равно остаются.
TaskQueue немного другие задачи решает. А кроме этого лимиты в 30 сек. и на get()/put() все равно остаются.
TaskQueue, генерация контента частями, кеширование. Это про Я.Маркет.
А про выгрузку-загрузку — ну я бы все же на bulk_uploader посмотрел. Готовое мнгопоточное решение запихивания данных в базу.
Сделайте отдельную «промежуточную таблицу», куда вы будете лоадером данные заливать, а потом уже через веб-интерфейс эти данные обрабатывать, «подтверждать» и чего там вам нужно. Или, опять же, Cron, да.
Вполне себе можно по расписанию из определенного места.
В решении таких задач в GAE приходится крутиться и придумывать всякие хитрые штуки :) Ну и главное — параллелить и разбивать задачу на кучу мелких подзадач, чтобы не вылезти за лимиты.
А про выгрузку-загрузку — ну я бы все же на bulk_uploader посмотрел. Готовое мнгопоточное решение запихивания данных в базу.
Сделайте отдельную «промежуточную таблицу», куда вы будете лоадером данные заливать, а потом уже через веб-интерфейс эти данные обрабатывать, «подтверждать» и чего там вам нужно. Или, опять же, Cron, да.
Вполне себе можно по расписанию из определенного места.
В решении таких задач в GAE приходится крутиться и придумывать всякие хитрые штуки :) Ну и главное — параллелить и разбивать задачу на кучу мелких подзадач, чтобы не вылезти за лимиты.
Не, крон то ясно для подгоовки периодики. Я для обновления имел ввиду. Ну и + батчи. Я предпочитаю у себя если индексов много и обьект большой, не более 10 в батче и распределять по таскам, типа лучше меньше и часто, и в батчах.
И последний вопрос. После разработки на GAE, променяли бы вы его на обычный платный хостинг?
Преимуществ у GAE на данный момент все-таки больше чем недостатков. На платном хостинге на мой взгляд имеет смысл делать проект который нельзя сделать на GAE.
Самое главное для меня — это отсутствие головной боли с покупкой/настройкой/поддержкой серверов.
Естественно речь о проектах требующих не меньше VPS.
Самое главное для меня — это отсутствие головной боли с покупкой/настройкой/поддержкой серверов.
Естественно речь о проектах требующих не меньше VPS.
Еще преимущество — надежность.
Все-таки кластер из кучи серверов в нескольких ДЦ — это очень серьезно. Я считаю, что это надежно.
VPS/дедик/колок может упасть — и это жопа :) Мало ли что с сервером могут сделать. Если конкуренты злые, то могут и украсть, и изъять…
Ну или надо несколько серверов для обеспечения надежности — а это уже дорого.
К слову, это характеристика клауда, а не только GAE.
Все-таки кластер из кучи серверов в нескольких ДЦ — это очень серьезно. Я считаю, что это надежно.
VPS/дедик/колок может упасть — и это жопа :) Мало ли что с сервером могут сделать. Если конкуренты злые, то могут и украсть, и изъять…
Ну или надо несколько серверов для обеспечения надежности — а это уже дорого.
К слову, это характеристика клауда, а не только GAE.
Интересно, что у вас favicon дефолтный :)
Спасибо за интересную статью! Будет интересно почитать о тестировании Amazon Web Services в вашем исполнении :)
По поводу своего домена: покупаете на стороне домен ВашДомен, регистрируете и устанавливаете для него Гугл Почту, после этого прямо в почте можно добавить ваше приложение из GAE и присвоить ему www.ВашДомен. А для просто www.ВашДомен делаете редирект 301 на ВашДомен.
Паривно конечно, но работает, если не охота сидеть на доменах *.appspot.com
У меня чистая статика тут www.roadslot.com. Действительно удобно, если уже знаком с технологией.
Паривно конечно, но работает, если не охота сидеть на доменах *.appspot.com
У меня чистая статика тут www.roadslot.com. Действительно удобно, если уже знаком с технологией.
Кстати, уже существуют и первые социальные сети UGC-типа, вполне успешно работающие на GAE.
Реальный работающий пример: enetri.com, украинский аналог Хабра.
Работает уже почти полгода, полет — нормальный, впечатления — положительные :)
Реальный работающий пример: enetri.com, украинский аналог Хабра.
Работает уже почти полгода, полет — нормальный, впечатления — положительные :)
Ого классная статья, еще бы про windows azure узнать
Sign up to leave a comment.
Стоит ли вам использовать Google AppEngine?