Производительность GridFS

    В интернете не так много статей о производительности GridFS, вот одна из них Serving files out of GridFS которая показывает, что отдача файлов из GridFS медленнее чем с диска в 6 раз.
    Но в той статье есть недочет — в тестировании обращение идет к одному файлу, а при этом файл кешируется на уровне nginx либо файловой системы что дает отрыв по сравнению с GridFS. Да и неплохо проверить свежий GridFS, 3 года прошло как никак.
    Поэтому я решил провести собственное тестирование, с обращением по разным именам файлов.

    Есть 52 тыс файлов — постеры к фильмам, общий объем 2Гб, средняя картинка весит 40кб. Копия файлов на ext4, копия в GridFS.
    Виртуалка 512Мб с 1 ядром. Ubuntu server 12.04 LTS 64bit, настройки Nginx/1.4.1 стандартные.
    Тест рассчитан на low-cost сервер, для мощных серверов результаты будут другие.

    Способы отдачи файлов:
    1) Nginx — статика
    2) Gevent через nginx
    3) 2 x Gevent через nginx (балансировка)
    4) Gevent напрямую
    5) Gevent через nginx (unix socket)
    для пунктов 2-5 использовался http сервер на Python + Gevent который отдавал файлы из GridFS

    Способы нагрузки:
    1) ol, t2 — Обращение к одному url, 2 потока
    2) ol, t10 — Обращение к одному url, 10 потоков
    3) t2 — Обращение к разным url, 2 потока
    4) t10 — Обращение к разным url, 10 потоков



    Детали:
    * Все тесты запускались 3 раза, в таблице среднее значение.
    * Обращение к разным url для всех тестов происходит по одному списку ссылок, ссылки содержат идентификатор файлов (в GridFS поиск идет по идентификатору)
    * В тестах где обращение идет к одному url, размер файла составляет 13.5 kb.
    * При отдаче через gevent, происходит кеширование последнего файла, поэтому в тестах где идет обращение на один url, обращение к GridFS не происходит и по сути замеряется скорость отдачи данных из Python.
    * Тест «one link» сделан в основном для определения пределов клиента.

    Клиент написан на Python, судя по результатам, его мощности хватает минимум на 1450 запрсов в секунду. Увеличение потоков, либо запуск как несколько процессов не дают большую производительность. Отсюда можно судить что сервер был «узким местом», что необходимо для тестирования.

    В результате мы получили информацию о том, что производительность GridFS не такая низкая как считалось ранее, по крайней мере на маленьких серверах.

    Ещё идеи:
    * Попробовать nginx-gridfs
    * uwsgi-gridfs
    * Отдача файлов через yield
    * Попробовать другие proxy сервера
    * Попробовать другие ФС (ZFS?)

    Так же планирую протестировать на мощном сервере.

    Исходники скриптов
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 16
      0
      Хм, а ведь не теперь, пожалуй, причин не иcпользовать гридФС для хранения статических ресурсов
        +1
        nginx-gridfs
        Это лишено смысла. Считайте, что на текущий момент нет такого модуля в nginx, поскольку существующий блокирует рабочий процесс на всех операциях.

        Вместо этого пункта рекомендую другой:
        • Настроить nginx


        После фразы настройки Nginx/1.4.1 стандартные можно выкидывать результаты nginx из теста.
          +4
          При таких объемах на современном сервере можно озаботиться полным кешированием картинок в память. Интереснее посмотреть результаты именно в рабочих условиях, на мощном железе, идеально настроенном софте и 30-50 гб данных.
            +2
            А если через nginx раздавать — то и заботиться не надо, pagecache сделают всю работу сам.
            30-50 Гб тоже довольно легко помещаются в память :) только сервер немного дороже. Если хочется сравнивать реальную производительность файловой системы против GridFS — то надо несколько сотен гигабайт данных и рандомно обращаться к данным.
            +4
            1200-1400 rps для статики по одному URL — это очень, очень мало для nginx даже на слабом железе. На упомянутой конфигурации (одно ядро, ext4, память в данном случае роли не играет) при чтении одного файла nginx (как и lighttpd) должен отдавать что-то под 7-10 тыс. ответов в секунду.

            Если пустить не на одном ядре, а на 4, то производительность подскочит ещё раза в три. 20..25 тыс. rps для nginx и одного файла — вот это нормальный уровень для средней машины.

            А 1200..1400 — это больше тянет на тормозной Apache с mpm_itk.
              0
              у знакомых был опыт хранения картинок в МонгоДБ, все бы ничего пока не легла база и на ее восстановление потребовалось очень большое время.
                0
                Сами картинки, закодированные в base64? А картинки большие были?
                  +1
                  В этом плане начал недавно присматриваться к OpenStack Swift. Оно, правда, без файловой системы, только для документов, но зато решает основную задачу GridFS — репликацию. При этом, в отличие от решений, типа Ceph, полностью распределено, без выделенного мастер-сервера метаданных.

                  Но до экспериментов пока не дошёл.
                    0
                    Для этого можно поднять репликационную ноду для бекапа — всегда будет копия свежих данных.
                      +1
                      Мы используем монгодб в продакшне, всем устраивает, объемы данных большие, очень.
                      Может Вы просто не использовали реплику-сет, раз у Вас легла вся база?
                      Да и за полтора года бд ни разу не упала, в чем у Вас причина падения была?
                        0
                        простите, а что вы в монго храните? объем данных? сруктура?
                          0
                          У меня в один из проектов: объем около 20Гб, содержит около 200-350 типов данных, файлов не более 2Гб, внутри пользовательская информация: сообщения, документы, комментарии, настройки и т.п. проекту 3 года, работает стабильно.
                            +1
                            Несколько разных нод, одна, работающая без реплики-сета (и шардинга, соответственно), обслуживает 60гб данных (~57 млн объектов) на одном сервере.
                            Другое хранилище содержит 3.8тб данных (1,6млрд объектов) на 4-ех серверах с шардингом.
                            БОльшая часть объектов в среднем размером 2 кб каждый.

                            У нас преимущественно одноуровневые объекты в коллекциях, они работают быстрее многоуровневых.

                            А по поводу падения — мы как-то специально закиллили один шард, восстанавливается он и правда долго(на 30гб данных и 25млн записей около 15-20 минут), так как разгребает свой журнал и проверяет целостность данных, без реплики-сета это и правда был бы провал.

                            P.S. После кропотной работы с монгой создаешь поневоле «рецепты её приготовления», которые помогают работать с ней и практически забыть о её обслуживании.
                            0
                            Со мной лишь поделились опытом, сайт очень посещаемый. В начале кэш был на уровне memcache, холодный запуск был тяжелый. Маленькие картинки (превьюшки) читать с диска было тяжело и было принято решение хранить это все монгоДБ, в каком виде к сожалению я не знаю. Знаю что восстанавливали после падения несколько часов. И своим комментом выше хотел просто напомнить, что бывают и такие случаи. А то по статье и комментам казалось что вообще нет минусов в таком решении.

                            Повторюсь, это все лишь слышал на словах. Подробностей к сожалению не знаю.
                              0
                              Минусы есть везде и всегда, нужно только попытаться их заставить работать на Вас и стать плюсами!

                              Просто после продолжительного времени работы БД под рельной большой нагрузкой мне сомнительно, что монго сама упала, хотя в Вашей формулировке это звучит именно так. Скорее я поверю, что вылетел сам сервер с битой памятью, развалившемся рейдом или оом-киллер убил монгу, потому что на сервере еще что-то располагалось кроме базы данных.

                              А вообще проблема, которую мы тут обсуждаем, — это издержки неправильной архитектуры (которая, к сожалению, в некоторых компаниях бывает из-за нежелания руководства выделять финансы на оверхед данных — репликацию).
                          0
                          Да и за полтора года бд ни разу не упала, в чем у Вас причина падения была?

                          Добавлю, 3 года используем MongoDB, сейчас активно 4 больших проекта, за это время не было ни одного «падения» (разрушения) БД.
                          Все большие проекты обязательно используют реплику сет, маленькие проекты просто бекапятся.

                          В интернете встречал — жаловались на стабильность в версии 1,6 и старше, но сейчас говорят MongoDB стала гораздо стабильней.

                          PS: не в ту ветку ответил, это ответ к greevex

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое