Примерно в марте 2011 года я протестировал GAE (версию Java) как потенциальную платформу для массивно параллельных вычислений. Дата актуальна, потому что GAE постоянно развивается. Я обнаружил, что приложение эффективно сокращалось примерно с 43,2X вычислительной пропускной способности. Кто-нибудь успешно использовал GAE для массивно-параллельных вычислений или добился гораздо более высокого вычислительного прироста? Для целей этого вопроса я буду произвольно определять массивно-параллельные вычисления, чтобы означать более чем 1000x вычислительную производительность.
Я использовал настольный клиент, который создавал несколько потоков для обращения к URL. Я использовал очереди задач GAE. Приложение требовало очень небольшого ввода и вырабатывало очень мало информации, будь то Datastore или HTML, поскольку оно было разработано для оценки вычислительной пропускной способности.
Поскольку часто рекомендуется держать задачи GAE менее 1 секунды (хотя неясно, применима ли эта рекомендация к задачам очереди задач), я пробовал различные варианты. Некоторые из моих результатов включены здесь. Как вы можете видеть, даже с 0,8-секундными задачами, в соответствии с рекомендацией менее 1 секунды, пропускная способность достигла максимума в 43,2 раза.
Elapsed Tasks SecondsOf Total Gain
Seconds Requested WorkPerTask Work
FLT (FEW LARGE TASKS)
15 72 1 72 4.9
103 72 20 1440 14.0
1524 72 400 28800 18.9
MST (MANY SMALL TASKS)
53 1000 0.8 800 15.1
63 2000 0.8 1600 25.4
127 4000 0.8 3200 25.2
313 4000 0.8 3200 10.2
258 8000 0.8 6400 24.8
177 8000 0.8 6400 36.2 (Have 5% of tasks do nothing.)
49 2000 0.8 1600 32.7 (Have 1% of tasks do nothing.)
37 2000 0.8 1600 43.2 (Have 5% of tasks do nothing.)
42 2000 0.8 1600 38.1 (Have 10% of tasks do nothing.)
249 2000 0.8 1600 6.4 (Have 50% of tasks do nothing.)
MLT (MANY LARGE TASKS)
6373 1000 200 200000 31.4
380 200 60 12000 31.6
Обратите внимание, что было нецелесообразно превышать 600 секунд для задач в очереди задач, поэтому самое большое, что я получил, было 400 секунд, просто чтобы оставить запас прочности. Случаи, когда некоторые задачи ничего не делают, заключаются в снижении среднего объема работы, которую должна выполнять каждая задача, чтобы повлиять на общий «учет» Google. Таким образом, каждая, скажем, 2000 задач, имеет 0,8 секунды работы, но лишние 222 задачи не работают, то есть 10% не работают.
Редактировать: @PeterRecore, я измеряю прирост пропускной способности, и это totalWorkInSeconds, деленное на elapsedTimeInSeconds, и это измеряется на клиенте. Клиент делает запросы и измеряет истекшее время до завершения всех задач GAE, что указывается каждой отправкой тривиально небольшого ответа. Я пытаюсь выяснить, можно ли использовать GAE в его нынешнем виде для создания приложения, которое достигает высоких значений прироста пропускной способности. В марте 2011 года это казалось маловероятным. Что насчет сегодня? и как это будет сделано или как ты на самом деле это сделал? какой уровень увеличения пропускной способности был достигнут? Как я уже сказал, использование Datastore минимально и состоит из каждой задачи, пишущей один тривиально маленький объект, когда задача выполнена. Каждая задача возвращается к целому числу, пропорциональному секундамOfWorkPerTask. GAE, раскручивающий экземпляры, является частью проблемы. Google как бы усугубляет эту проблему, говоря людям, что они предпочитают менее чем за секунду задачи Проблема смягчается, если у меня большие задачи, потому что тогда создание экземпляров - это меньший процент от числа используемых циклов.