Комментарии 74
Пробовал на java тестить? всё так же?)
Вот есть приложение на java
Объём данных по больше и скорость работы нормальная.
Там приводится тест Datastore и memcached.
Объём данных по больше и скорость работы нормальная.
Там приводится тест Datastore и memcached.
Корень проблемы — в производительности системы хранения данных. От языка это сильно не зависит.
А по сути — нет, не пробовал. Основная платформа все-таки Python, и сам гугл её использует.
А по сути — нет, не пробовал. Основная платформа все-таки Python, и сам гугл её использует.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Да, теперь хотелось бы услышать результаты подобной проверки по амазонскому сервису.
помоему 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 мс — это на последовательные запросы из одного приложения. Но из-за локов в транзакционных записях могут быть проблеммы со скоростью, тут архитектурой заниматься надо.
НЛО прилетело и опубликовало эту надпись здесь
Ну кратко есть тут. Чтиво ровно на 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 раза
НЛО прилетело и опубликовало эту надпись здесь
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 узнать
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стоит ли вам использовать Google AppEngine?