Столкнувшись с вопросом выбора базы данных для проекта, провел небольшое исследование Google App Engine на предмет скорости работы с данными. Результаты исследования оформил в виде таблиц.
Эти подсчеты сэкономят время тем, кто ищет площадку для размещения своего проекта, но не уверен подходит ли ему Google App Engine. Кроме того эти таблицы можно использовать как некую «шпаргалку», чтобы примерно ориентироваться сколько времени займет обработка запроса и как его лучше оптимизировать.
При прочтении статьи следует помнить что Google App Engine действительно автоматически масштабируемый. Одна из статей ввела меня в заблуждение и я уже было начал в этом сомневаться. Проверил на практике:
При частых запросах даже с одного IP-адреса, GAE автоматически поднимает новые инстанции и равномерно распределяет нагрузку между ними. На рисунке выше добавлено 8 инстанций и это далеко не предел.
Все замеры, приведенные в статье, актуальны для одной инстанции. При увеличении нагрузки на сайт суммарная скорость выполнения запросов возрастет (за счет автоматического добавления новых инстанций), а вот скорость исполнения одного запроса не изменится (если быть точнее, снизится в пределах 30%).
Условия тестирования. Для тестов хранилища использовалась таблица с 1 ключом и 1 строковым значением. Размер строки всегда был равен 500 символов (скажем так, размер среднего комментария в блоге или новостном сайте). Стоит заметить, что при увеличении размера объекта скорость чтения/записи изменяется не значительно.
Тест 1. Запись в хранилище данных Google BigTable
Запись по оному значению:
Пакетная запись:
Как видно, стоимость пакетной записи немногим меньше стоимости записи по одному значению. А вот скорость исполнения пакетной записи до 10 раз выше.
Стоимость записи:
Ориентировочно на 10 записей уходит 1 процессорная секунда (чуть быстрее, берем с запасом):
Максимум записей на 1 запрос
Для сравнения: SQL Server Express R2 на Amazon EC2 Micro: 1 секунда 500 записей.
*Запросы, занимающие более 0.5 секунды вызывают дискомфорт. За один запрос, по возможности, не следует выполнять больше записей, чем указано в таблице (кроме того, необходимо учитывать и другие операции).
Тест 2. Чтение данных из хранилища Google BigTable и отображение их на странице
Чтение по оному значению:
Пакетное чтение (выборка по условию > && <)
Аналогично записи: процессорного времени тратится примерно одинаково: и при пакетном чтении и при единичном. А вот реального времени при пакетном чтении уходит раз в 10 меньше.
Стоимость чтения:
Ориентировочно в 6 раз дешевле записи. 1 процессорная секунда – 60 чтений:
Максимум чтений за 1 запрос
*Запросы, занимающие более 0.5 секунды вызывают дискомфорт. За один запрос, по возможности, не следует выполнять больше чтений, чем указано в таблице (кроме того, необходимо учитывать и другие операции).
Тест 3. Хранение данных в Memcache
Запись и чтение выполняются за примерно одинаковое время (чтение чуть быстрее, но для упрощения округлим).
Стоимость Memcache
Примерно в 3 раза дешевле чтения из базы данных и в 15 раз дешевле записи в базу данных.
Максимум операций за 1 запрос
*Запросы, занимающие более 0.5 секунды вызывают дискомфорт. За один запрос, по возможности, не следует выполнять больше операций с Memcache, чем указано в таблице (кроме того, необходимо учитывать и другие операции).
Тест 4. Масштабирование
Все что написано выше — касается одной инстанции и одного запроса. Суммарная скорость выполнения всех запросов может быть значительно выше.
Практически провел такой эксперимент. Было создано приложение выполняющее 5 записей в базу данных и 100 чтений с выводом информации на страницу (размер динамических данных 500 символов * 100 = 50 Кб UTF-8). Расход CPU Time: 1300 ms на запрос.
Это приложение бомбардировалось запросами в несколько потоков (сервер-бомбардировщик с каналом 100 МБит). Результаты бомбардировок:
Итак, при увеличении нагрузки в 10 раз суммарная скорость обработки запросов возросла примерно в 7 раз (около 150 ms 1 запрос, всего 10 * 7 = 70 запросов в секунду).
В результате эксперимента за 3 минуты было выполнено 16 тыс. запросов (10 инстанций, по 1600 запросов на одну) и потрачено 800 МБайт трафика.
Вывод
Вывод для себя сделал такой: Google в очередной раз обогнал на несколько шагов всех своих конкурентов по облачному высоко-масштабируемому хостингу. Цены на обработку данных, конечно, не маленькие, но уникальная ценовая политика выгодно отличает GAE от прочих облачных сервисов. Хотелось бы, конечно, увидеть достойный ответ Micorsoft на Google App Engine, но очень сомнительно что мы дождемся этого, так как подобные технологии требуют владения принципом KISS.
UPDATE по поводу картинки
Смотрю, в комментариях начались упреки в сторону Google по поводу картинки в статье, мол GAE не выдержал т.н. «хабраэффект». Это все не соответствует действительности.
Картинка временно (с примерно 1 часа ночи до 7 часов утра) пропала так как закончился бесплатный лимит. Добавил 16 часов времени, думаю хватит. Замечу, что еще до того как разместил счетчик на Хабре, уже 30% бесплатного лимита израсходовал на эксперименты. Оставшихся 70% хватило на 20 тысяч показов счетчика (с учетом его медлительности — не так уж и мало).
Кстати, это не просто картинка а счетчик. Картинка с результатами подсчета создается программным способом с помощью библиотеки org.toyz.litetext для каждого запроса (кеширование отключено). Так как библиотека org.toyz.litetext работает очень медленно (я ее не писал) — каждый запрос потребляет 500 ms процессорного времени. Кроме того информация о каждом отображении заносится в базу данных.
Сейчас (по Москве около 9 часов) около 200 просмотров в минуту (счетчик каждый видит и может посчитать самостоятельно). GAE держит включенными 13-15 инстанций (сейчас 13, было и 15). Нагрузка все еще повышается.Сколько инстанций будет в пике — отпишу позже. Детально (с графиками) написал в новой статье: habrahabr.ru/blogs/gae/115731
Эти подсчеты сэкономят время тем, кто ищет площадку для размещения своего проекта, но не уверен подходит ли ему Google App Engine. Кроме того эти таблицы можно использовать как некую «шпаргалку», чтобы примерно ориентироваться сколько времени займет обработка запроса и как его лучше оптимизировать.
При прочтении статьи следует помнить что Google App Engine действительно автоматически масштабируемый. Одна из статей ввела меня в заблуждение и я уже было начал в этом сомневаться. Проверил на практике:
При частых запросах даже с одного IP-адреса, GAE автоматически поднимает новые инстанции и равномерно распределяет нагрузку между ними. На рисунке выше добавлено 8 инстанций и это далеко не предел.
Все замеры, приведенные в статье, актуальны для одной инстанции. При увеличении нагрузки на сайт суммарная скорость выполнения запросов возрастет (за счет автоматического добавления новых инстанций), а вот скорость исполнения одного запроса не изменится (если быть точнее, снизится в пределах 30%).
Условия тестирования. Для тестов хранилища использовалась таблица с 1 ключом и 1 строковым значением. Размер строки всегда был равен 500 символов (скажем так, размер среднего комментария в блоге или новостном сайте). Стоит заметить, что при увеличении размера объекта скорость чтения/записи изменяется не значительно.
Тест 1. Запись в хранилище данных Google BigTable
Запись по оному значению:
| Действие | Процессорное время | Реальное время |
|---|---|---|
| 1 запись в базу данных | 90 ms | 40 ms |
| 10 записей по очереди | 750 ms | 250 ms |
| 100 записей по очереди | 7250 ms | 2100 ms |
| 1000 записей по очереди | 71000 ms | 28000 ms |
Пакетная запись:
| Действие | Процессорное время | Реальное время |
|---|---|---|
| 10 записей одним запросом | 670 ms | 60 ms |
| 100 записей одним запросом | 6600 ms | 370 ms |
| 1000 записей одним запросом | 65000 ms | 2500 ms |
Как видно, стоимость пакетной записи немногим меньше стоимости записи по одному значению. А вот скорость исполнения пакетной записи до 10 раз выше.
Стоимость записи:
Ориентировочно на 10 записей уходит 1 процессорная секунда (чуть быстрее, берем с запасом):
| Сумма | Сколько записей можно купить |
|---|---|
| 1 цент | 3600 записей |
| 1 доллар | 360 тыс. записей |
Максимум записей на 1 запрос
| Действие | Комфортный максимум* | Технический максимум |
|---|---|---|
| Поочередная запись | 20 | 1 тыс. |
| Пакетная запись | 200 | 10 тыс. |
Для сравнения: SQL Server Express R2 на Amazon EC2 Micro: 1 секунда 500 записей.
*Запросы, занимающие более 0.5 секунды вызывают дискомфорт. За один запрос, по возможности, не следует выполнять больше записей, чем указано в таблице (кроме того, необходимо учитывать и другие операции).
Тест 2. Чтение данных из хранилища Google BigTable и отображение их на странице
Чтение по оному значению:
| Действие | Процессорное время | Реальное время |
|---|---|---|
| 1 чтение | 31 ms | 20 ms |
| 10 чтений по очереди | 160 ms | 100 ms |
| 100 чтений по очереди | 1600 ms | 750 ms |
| 1000 чтений по очереди | 12000 ms | 8500 ms |
Пакетное чтение (выборка по условию > && <)
| Действие | Процессорное время | Реальное время |
|---|---|---|
| 10 записей одним запросом | 100 ms | 25 ms |
| 100 записей одним запросом | 1000 ms | 80 ms |
| 1000 записей одним запросом | 9600 ms | 400 ms |
Аналогично записи: процессорного времени тратится примерно одинаково: и при пакетном чтении и при единичном. А вот реального времени при пакетном чтении уходит раз в 10 меньше.
Стоимость чтения:
Ориентировочно в 6 раз дешевле записи. 1 процессорная секунда – 60 чтений:
| Сумма | Сколько раз можно прочитать |
|---|---|
| 1 цент | 21 тыс. чтений |
| 1 доллар | 2 млн. чтений |
Максимум чтений за 1 запрос
| Действие | Комфортный максимум* | Технический максимум |
|---|---|---|
| Поочередное чтение | 60 | 3 тыс. |
| Пакетное чтение | 1100 | 50 тыс. |
*Запросы, занимающие более 0.5 секунды вызывают дискомфорт. За один запрос, по возможности, не следует выполнять больше чтений, чем указано в таблице (кроме того, необходимо учитывать и другие операции).
Тест 3. Хранение данных в Memcache
Запись и чтение выполняются за примерно одинаковое время (чтение чуть быстрее, но для упрощения округлим).
| Количество операций | Время процессорное/реальное |
|---|---|
| 1 | 23 cpu/11 ms |
| 10 | 94 cpu/50 ms |
| 100 | 300 cpu/300 ms |
| 1000 | 3000 cpu/3000 ms |
Стоимость Memcache
Примерно в 3 раза дешевле чтения из базы данных и в 15 раз дешевле записи в базу данных.
| Сумма | Сколько операций можно купить |
|---|---|
| 1 цент | 60 тыс. операций чтения/записи |
| 1 доллар | 6 млн. операций чтения/записи |
Максимум операций за 1 запрос
| Действие | Комфортный максимум* | Технический максимум |
|---|---|---|
| Чтение/запись | 150 | 9 тыс. |
*Запросы, занимающие более 0.5 секунды вызывают дискомфорт. За один запрос, по возможности, не следует выполнять больше операций с Memcache, чем указано в таблице (кроме того, необходимо учитывать и другие операции).
Тест 4. Масштабирование
Все что написано выше — касается одной инстанции и одного запроса. Суммарная скорость выполнения всех запросов может быть значительно выше.
Практически провел такой эксперимент. Было создано приложение выполняющее 5 записей в базу данных и 100 чтений с выводом информации на страницу (размер динамических данных 500 символов * 100 = 50 Кб UTF-8). Расход CPU Time: 1300 ms на запрос.
Это приложение бомбардировалось запросами в несколько потоков (сервер-бомбардировщик с каналом 100 МБит). Результаты бомбардировок:
| Количество потоков | Время 1-го запроса |
|---|---|
| 1 | 100 ms |
| 10 | 150 ms |
Итак, при увеличении нагрузки в 10 раз суммарная скорость обработки запросов возросла примерно в 7 раз (около 150 ms 1 запрос, всего 10 * 7 = 70 запросов в секунду).
В результате эксперимента за 3 минуты было выполнено 16 тыс. запросов (10 инстанций, по 1600 запросов на одну) и потрачено 800 МБайт трафика.
Вывод
Вывод для себя сделал такой: Google в очередной раз обогнал на несколько шагов всех своих конкурентов по облачному высоко-масштабируемому хостингу. Цены на обработку данных, конечно, не маленькие, но уникальная ценовая политика выгодно отличает GAE от прочих облачных сервисов. Хотелось бы, конечно, увидеть достойный ответ Micorsoft на Google App Engine, но очень сомнительно что мы дождемся этого, так как подобные технологии требуют владения принципом KISS.
UPDATE по поводу картинки
Смотрю, в комментариях начались упреки в сторону Google по поводу картинки в статье, мол GAE не выдержал т.н. «хабраэффект». Это все не соответствует действительности.
Картинка временно (с примерно 1 часа ночи до 7 часов утра) пропала так как закончился бесплатный лимит. Добавил 16 часов времени, думаю хватит. Замечу, что еще до того как разместил счетчик на Хабре, уже 30% бесплатного лимита израсходовал на эксперименты. Оставшихся 70% хватило на 20 тысяч показов счетчика (с учетом его медлительности — не так уж и мало).
Кстати, это не просто картинка а счетчик. Картинка с результатами подсчета создается программным способом с помощью библиотеки org.toyz.litetext для каждого запроса (кеширование отключено). Так как библиотека org.toyz.litetext работает очень медленно (я ее не писал) — каждый запрос потребляет 500 ms процессорного времени. Кроме того информация о каждом отображении заносится в базу данных.
Сейчас (по Москве около 9 часов) около 200 просмотров в минуту (счетчик каждый видит и может посчитать самостоятельно). GAE держит включенными 13-15 инстанций (сейчас 13, было и 15). Нагрузка все еще повышается.
