seaweedfs
3.80
SeaweedFS — это независимый проект с открытым исходным кодом, имеющий лицензию Apache. Его постоянное развитие стало возможным исключительно благодаря поддержке этих замечательных сторонников. Если вы хотите сделать SeaweedFS еще сильнее, рассмотрите возможность присоединиться к нашим спонсорам на Patreon.
Ваша поддержка будет очень признательна мне и другим сторонникам!
docker run -p 8333:8333 chrislusf/seaweedfs server -s3
weed или weed.exe . Или запустите go install github.com/seaweedfs/seaweedfs/weed@latest .weed server -dir=/some/data/dir -s3 чтобы запустить один главный сервер, один сервер томов, один фильтр и один шлюз S3. Кроме того, чтобы увеличить емкость, просто добавьте больше серверов томов, запустив weed volume -dir="/some/data/dir2" -mserver="<master_host>:9333" -port=8081 локально, на другом компьютере или на тысячи машин. Вот и все!
SeaweedFS — это простая и масштабируемая распределенная файловая система. Есть две цели:
SeaweedFS начиналась как хранилище объектов для эффективной обработки небольших файлов. Вместо управления всеми метаданными файлов на центральном мастере центральный мастер управляет только томами на серверах томов, а эти серверы томов управляют файлами и их метаданными. Это снижает нагрузку на центральный главный сервер и распределяет метаданные файлов по серверам томов, обеспечивая более быстрый доступ к файлам (O(1), обычно только одна операция чтения с диска).
Для метаданных каждого файла требуется всего 40 байт дискового пространства. Операции чтения с диска O(1) настолько просты, что вы можете проверить производительность в реальных случаях использования.
SeaweedFS началась с реализации проектного документа Haystack от Facebook. Кроме того, SeaweedFS реализует стирающее кодирование на основе идей f4: системы хранения Warm BLOB от Facebook и имеет много общего с Tectonic Filesystem от Facebook.
Помимо хранилища объектов, дополнительный Filer может поддерживать каталоги и атрибуты POSIX. Filer — это отдельный линейно масштабируемый сервер без сохранения состояния с настраиваемыми хранилищами метаданных, например, MySql, Postgres, Redis, Cassandra, HBase, Mongodb, Elastic Search, LevelDB, RocksDB, Sqlite, MemSql, TiDB, Etcd, CockroachDB, YDB и т. д.
Для любых распределенных хранилищ значений ключей большие значения можно выгрузить в SeaweedFS. Благодаря высокой скорости доступа и линейно масштабируемой емкости SeaweedFS может работать как распределенное хранилище ключей с большим значением.
SeaweedFS может прозрачно интегрироваться с облаком. Благодаря «горячим» данным в локальном кластере и «теплым» данным в облаке со временем доступа O(1) SeaweedFS может обеспечить как быстрое время локального доступа, так и эластичную емкость облачного хранилища. Более того, стоимость API доступа к облачному хранилищу сведена к минимуму. Быстрее и дешевле, чем прямое облачное хранилище!
Вернуться к оглавлению
Вернуться к оглавлению
Вернуться к оглавлению
По умолчанию главный узел работает на порту 9333, а узлы томов — на порту 8080. Давайте запустим один главный узел и два узла тома на портах 8080 и 8081. В идеале их следует запускать с разных машин. В качестве примера мы будем использовать localhost.
SeaweedFS использует операции HTTP REST для чтения, записи и удаления. Ответы предоставляются в формате JSON или JSONP.
> ./weed master
> weed volume -dir="/tmp/data1" -max=5 -mserver="localhost:9333" -port=8080 &
> weed volume -dir="/tmp/data2" -max=10 -mserver="localhost:9333" -port=8081 &
Чтобы загрузить файл: сначала отправьте HTTP-запрос POST, PUT или GET в /dir/assign чтобы получить fid и URL-адрес сервера тома:
> curl http://localhost:9333/dir/assign
{"count":1,"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}
Во-вторых, чтобы сохранить содержимое файла, отправьте HTTP-запрос, состоящий из нескольких частей, по адресу url + '/' + fid из ответа:
> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}
Для обновления отправьте еще один запрос POST с обновленным содержимым файла.
Для удаления отправьте HTTP-запрос DELETE на тот же url + '/' + fid :
> curl -X DELETE http://127.0.0.1:8080/3,01637037d6
Теперь вы можете сохранить fid , в данном случае 3,01637037d6, в поле базы данных.
Число 3 в начале представляет идентификатор тома. После запятой это один ключ файла, 01, и файл cookie, 637037d6.
Идентификатор тома представляет собой 32-битное целое число без знака. Ключ файла представляет собой беззнаковое 64-битное целое число. Файл cookie представляет собой 32-битное целое число без знака, используемое для предотвращения угадывания URL-адреса.
Ключ файла и файл cookie закодированы в шестнадцатеричном формате. Вы можете сохранить кортеж <volume id, file key, file cookie> в своем собственном формате или просто сохранить fid в виде строки.
Теоретически, если храниться в виде строки, вам понадобится 8+1+16+8=33 байта. Символа char(33) было бы достаточно, если не более чем достаточно, поскольку для большинства применений не потребуется 2^32 тома.
Если пространство действительно важно, вы можете сохранить идентификатор файла в своем собственном формате. Вам понадобится одно 4-байтовое целое число для идентификатора тома, 8-байтовое длинное число для ключа файла и 4-байтовое целое число для файла cookie. Так что 16 байт более чем достаточно.
Вот пример того, как отобразить URL-адрес.
Сначала найдите URL-адреса сервера томов по идентификатору тома файла:
> curl http://localhost:9333/dir/lookup?volumeId=3
{"volumeId":"3","locations":[{"publicUrl":"localhost:8080","url":"localhost:8080"}]}
Поскольку (обычно) серверов томов не так уж много, а тома перемещаются нечасто, большую часть времени можно кэшировать результаты. В зависимости от типа репликации один том может иметь несколько расположений реплик. Просто случайно выберите одно место для чтения.
Теперь вы можете взять общедоступный URL-адрес, отобразить URL-адрес или напрямую прочитать его с сервера тома через URL-адрес:
http://localhost:8080/3,01637037d6.jpg
Обратите внимание, что мы добавляем сюда расширение файла «.jpg». Это необязательный и всего лишь один из способов указать клиентом тип содержимого файла.
Если вам нужен более красивый URL-адрес, вы можете использовать один из этих альтернативных форматов URL-адресов:
http://localhost:8080/3/01637037d6/my_preferred_name.jpg
http://localhost:8080/3/01637037d6.jpg
http://localhost:8080/3,01637037d6.jpg
http://localhost:8080/3/01637037d6
http://localhost:8080/3,01637037d6
Если вы хотите получить масштабированную версию изображения, вы можете добавить некоторые параметры:
http://localhost:8080/3/01637037d6.jpg?height=200&width=200
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fit
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fill
SeaweedFS применяет стратегию репликации на уровне тома. Итак, когда вы получаете идентификатор файла, вы можете указать стратегию репликации. Например:
curl http://localhost:9333/dir/assign?replication=001
Параметры репликации:
000: no replication
001: replicate once on the same rack
010: replicate once on a different rack, but same data center
100: replicate once on a different data center
200: replicate twice on two different data center
110: replicate once on a different rack, and once on a different data center
Более подробную информацию о репликации можно найти на вики.
Вы также можете установить стратегию репликации по умолчанию при запуске главного сервера.
Серверы томов можно запустить с определенным именем центра обработки данных:
weed volume -dir=/tmp/1 -port=8080 -dataCenter=dc1
weed volume -dir=/tmp/2 -port=8081 -dataCenter=dc2
При запросе ключа файла дополнительный параметр «dataCenter» может ограничить назначенный том конкретным центром обработки данных. Например, это указывает, что назначенный том должен быть ограничен «dc1»:
http://localhost:9333/dir/assign?dataCenter=dc1
Вернуться к оглавлению
Обычно распределенные файловые системы разбивают каждый файл на фрагменты, центральный мастер хранит сопоставление имен файлов, индексов фрагментов с дескрипторами фрагментов, а также то, какие фрагменты есть на каждом сервере фрагментов.
Основным недостатком является то, что центральный мастер не может эффективно обрабатывать множество небольших файлов, а поскольку все запросы на чтение должны проходить через мастер фрагментов, он может плохо масштабироваться для многих одновременных пользователей.
Вместо управления частями SeaweedFS управляет томами данных на главном сервере. Каждый том данных имеет размер 32 ГБ и может содержать множество файлов. И каждый узел хранения может иметь множество томов данных. Таким образом, главному узлу необходимо хранить только метаданные о томах, которые представляют собой довольно небольшой объем данных и, как правило, стабильны.
Фактические метаданные файла хранятся в каждом томе на серверах томов. Поскольку каждый сервер томов управляет метаданными файлов только на своем собственном диске (всего 16 байт на каждый файл), при любом доступе к файлу метаданные файла могут считываться только из памяти, и для фактического чтения данных файла требуется только одна дисковая операция.
Для сравнения предположим, что структура индексного дескриптора xfs в Linux составляет 536 байт.
Архитектура довольно проста. Фактические данные хранятся в томах на узлах хранения. Один сервер томов может иметь несколько томов и может поддерживать доступ как для чтения, так и для записи с базовой аутентификацией.
Все тома управляются главным сервером. Главный сервер содержит идентификатор тома, сопоставленный с сервером томов. Это довольно статичная информация, и ее можно легко кэшировать.
При каждом запросе на запись главный сервер также генерирует ключ файла, который представляет собой растущее 64-битное целое число без знака. Поскольку запросы на запись обычно не так часты, как запросы на чтение, один главный сервер должен хорошо справляться с параллелизмом.
Когда клиент отправляет запрос на запись, главный сервер возвращает (идентификатор тома, ключ файла, файл cookie, URL-адрес узла тома) для файла. Затем клиент связывается с узлом тома и отправляет POST содержимое файла.
Когда клиенту необходимо прочитать файл на основе (идентификатора тома, ключа файла, файла cookie), он запрашивает у главного сервера идентификатор тома (URL-адрес узла тома, общедоступный URL-адрес узла тома) или извлекает его из кэша. Затем клиент может ПОЛУЧИТЬ контент или просто отобразить URL-адрес на веб-страницах и позволить браузерам получать контент.
Подробную информацию о процессе записи и чтения см. в примере.
В текущей реализации каждый том может содержать 32 гибибайта (32 ГБ или 8x2^32 байта). Это потому, что мы выравниваем содержимое по 8 байтам. Мы можем легко увеличить это значение до 64 ГиБ, или 128 ГиБ, или более, изменив две строки кода за счет некоторого потраченного впустую пространства заполнения из-за выравнивания.
Тома могут иметь размер 4 гибибайта (4 ГБ или 2 ^ 32 байта). Таким образом, общий размер системы составляет 8 x 4 ГБ x 4 ГБ, что составляет 128 эксбибайт (128EiB или 2 ^ 67 байт).
Размер каждого отдельного файла ограничен размером тома.
Вся метаинформация файлов, хранящаяся на сервере томов, доступна для чтения из памяти без доступа к диску. Каждый файл занимает всего лишь 16-байтовую запись карты <64-битный ключ, 32-битное смещение, 32-битный размер>. Конечно, каждая запись на карте имеет свою собственную стоимость места на карте. Но обычно место на диске заканчивается раньше, чем память.
Серверы локальных томов работают намного быстрее, в то время как облачные хранилища имеют эластичную емкость и на самом деле более экономичны, если к ним не часто обращаются (обычно загрузка бесплатна, но доступ относительно дорог). Благодаря структуре только для добавления и времени доступа O(1) SeaweedFS может использовать преимущества как локального, так и облачного хранилища, выгружая «теплые» данные в облако.
Обычно «горячие» данные — свежие, а «горячие» — старые. SeaweedFS помещает вновь созданные тома на локальные серверы и при необходимости загружает старые тома в облако. Если доступ к старым данным осуществляется реже, это буквально дает вам неограниченную емкость с ограниченными локальными серверами и при этом быструю обработку новых данных.
Благодаря времени доступа O(1) стоимость задержки в сети поддерживается на минимальном уровне.
Если горячие/теплые данные разделены на 20 серверов как 20/80, вы можете достичь емкости хранения 100 серверов. Это экономия 80%! Или вы можете перепрофилировать 80 серверов для хранения новых данных и увеличить пропускную способность хранилища в 5 раз.
Вернуться к оглавлению
Большинство других распределенных файловых систем кажутся более сложными, чем необходимо.
SeaweedFS должна быть быстрой и простой как в настройке, так и в работе. Если вы не понимаете, как это работает, когда доберетесь сюда, мы потерпели неудачу! Пожалуйста, поднимите проблему, задав вопросы, или обновите этот файл, добавив разъяснения.
SeaweedFS постоянно движется вперед. То же самое и с другими системами. Эти сравнения могут быстро устареть. Пожалуйста, помогите держать их в курсе.
Вернуться к оглавлению
HDFS использует фрагментный подход для каждого файла и идеально подходит для хранения больших файлов.
SeaweedFS идеально подходит для быстрого и одновременного обслуживания относительно небольших файлов.
SeaweedFS также может хранить очень большие файлы, разделяя их на управляемые фрагменты данных, и сохранять идентификаторы файлов фрагментов данных в мета-блоке. Это управляется инструментом «загрузки/выгрузки сорняков», и главный сервер сорняков или серверы томов не имеют к этому никакого отношения.
Вернуться к оглавлению
Архитектуры в основном одинаковы. Целью SeaweedFS является быстрое хранение и чтение файлов с простой и плоской архитектурой. Основные различия заключаются в том,
| Система | Метаданные файла | Содержимое файла прочитано | ПОСИКС | ОТДЫХ API | Оптимизирован для большого количества небольших файлов. |
|---|---|---|---|---|---|
| Морские водорослиFS | идентификатор тома поиска, кэшируемый | O(1) поиск по диску | Да | Да | |
| Файлер SeaweedFS | Линейно масштабируемый, настраиваемый | O(1) поиск по диску | ПРЕДОХРАНИТЕЛЬ | Да | Да |
| ГлюстерФС | хеширование | ПРЕДОХРАНИТЕЛЬ, НФС | |||
| Цеф | хеширование + правила | ПРЕДОХРАНИТЕЛЬ | Да | ||
| MooseFS | в памяти | ПРЕДОХРАНИТЕЛЬ | Нет | ||
| МинИО | отдельный метафайл для каждого файла | Да | Нет |
Вернуться к оглавлению
GlusterFS хранит файлы (как каталоги, так и контент) в настраиваемых томах, называемых «кирпичиками».
GlusterFS хэширует путь и имя файла в идентификаторы и назначает их виртуальным томам, а затем сопоставляет их с «кирпичиками».
Вернуться к оглавлению
MooseFS предпочитает игнорировать проблемы с небольшими файлами. Из руководства moosefs 3.0 «даже небольшой файл будет занимать 64 КБ плюс дополнительно 4 КБ контрольных сумм и 1 КБ для заголовка», поскольку он «изначально был разработан для хранения больших объемов (например, нескольких тысяч) очень больших файлов»
Главный сервер MooseFS хранит все метаданные в памяти. Та же проблема, что и у узла имени HDFS.
Вернуться к оглавлению
Ceph можно настроить аналогично SeaweedFS в качестве хранилища ключей->blob. Это гораздо сложнее, с необходимостью поддерживать слои поверх него. Вот более подробное сравнение
SeaweedFS имеет централизованную главную группу для поиска свободных томов, а Ceph использует серверы хеширования и метаданных для поиска своих объектов. Наличие централизованного мастера упрощает кодирование и управление.
Ceph, как и SeaweedFS, основан на хранилище объектов RADOS. Ceph довольно сложен и имеет неоднозначные отзывы.
Ceph использует хеширование CRUSH для автоматического управления размещением данных, что позволяет эффективно находить данные. Но данные должны быть размещены по алгоритму CRUSH. Любая неправильная конфигурация может привести к потере данных. Изменения топологии, такие как добавление новых серверов для увеличения емкости, приведут к миграции данных с высокой стоимостью ввода-вывода для соответствия алгоритму CRUSH. SeaweedFS размещает данные, присваивая их любым доступным для записи томам. Если запись на один том не удалась, просто выберите для записи другой том. Добавление дополнительных томов также настолько просто, насколько это возможно.
SeaweedFS оптимизирован для небольших файлов. Небольшие файлы хранятся как один непрерывный блок содержимого, между файлами которого не более 8 неиспользуемых байтов. Доступ к небольшому файлу равен O(1) чтению с диска.
SeaweedFS Filer использует готовые хранилища, такие как MySql, Postgres, Sqlite, Mongodb, Redis, Elastic Search, Cassandra, HBase, MemSql, TiDB, CockroachCB, Etcd, YDB, для управления каталогами файлов. Эти магазины проверены, масштабируемы и ими проще управлять.
| Морские водорослиFS | сравнимо с Ceph | преимущество |
|---|---|---|
| Владелец | МДС | проще |
| Объем | экранное меню | оптимизирован для небольших файлов |
| Филер | Цеф ФС | линейно масштабируемый, настраиваемый, O(1) или O(logN) |
Вернуться к оглавлению
MinIO тесно связан с AWS S3 и идеально подходит для тестирования S3 API. У него хороший пользовательский интерфейс, политики, управление версиями и т. д. SeaweedFS пытается наверстать упущенное. Также возможно позже поставить MinIO в качестве шлюза перед SeaweedFS.
Метаданные MinIO находятся в простых файлах. Каждая запись файла потребует дополнительных операций записи в соответствующий метафайл.
MinIO не имеет оптимизации для большого количества маленьких файлов. Файлы просто сохраняются на локальных дисках как есть. Плюс дополнительный метафайл и фрагменты для стирающего кодирования только усугубляют проблему LOSF.
MinIO имеет несколько дисковых операций ввода-вывода для чтения одного файла. SeaweedFS имеет скорость чтения с диска O(1), даже для файлов с стирающим кодом.
MinIO имеет постоянное стирающее кодирование. SeaweedFS использует репликацию «горячих» данных для более высокой скорости и дополнительно применяет стирающее кодирование к «горячим» данным.
MinIO не поддерживает POSIX-подобный API.
У MinIO есть особые требования к расположению хранилища. Невозможно гибко регулировать мощность. В SeaweedFS просто запустите один том-сервер, указывающий на главный сервер. Вот и все.
Это супер-интересный проект! И нам нужны помощники и поддержка!
Вернуться к оглавлению
Руководство по установке для пользователей, не знакомых с golang
Шаг 1: установите go на свой компьютер и настройте среду, следуя инструкциям по адресу:
https://golang.org/doc/install
обязательно определите свой $GOPATH
Шаг 2: проверьте этот репозиторий:
git clone https://github.com/seaweedfs/seaweedfs.gitШаг 3. Загрузите, скомпилируйте и установите проект, выполнив следующую команду.
cd seaweedfs/weed && make install Как только это будет сделано, вы найдете исполняемый файл «weed» в вашем каталоге $GOPATH/bin
Вернуться к оглавлению
Тестирование производительности чтения в SeaweedFS по сути становится проверкой производительности произвольной скорости чтения вашего жесткого диска. Жесткие диски обычно имеют скорость 100–200 МБ/с.
Чтобы изменить или удалить небольшие файлы, SSD должен удалять целый блок за раз и перемещать содержимое существующих блоков в новый блок. SSD работает быстро, когда он новый, но со временем он фрагментируется, и вам придется собирать мусор, уплотняя блоки. SeaweedFS совместима с SSD, поскольку предназначена только для добавления. Удаление и сжатие выполняются на уровне тома в фоновом режиме, не замедляя чтение и не вызывая фрагментации.
Вернуться к оглавлению
Мои собственные ненаучные результаты на одном компьютере на Mac Book с твердотельным диском, процессор: 1 Intel Core i7 2,6 ГГц.
Запишите 1 миллион файлов размером 1 КБ:
Concurrency Level: 16
Time taken for tests: 66.753 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106789009 bytes
Requests per second: 15708.23 [#/sec]
Transfer rate: 16191.69 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.3 1.0 84.3 0.9
Percentage of the requests served within a certain time (ms)
50% 0.8 ms
66% 1.0 ms
75% 1.1 ms
80% 1.2 ms
90% 1.4 ms
95% 1.7 ms
98% 2.1 ms
99% 2.6 ms
100% 84.3 ms
Случайное чтение 1 миллиона файлов:
Concurrency Level: 16
Time taken for tests: 22.301 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106812873 bytes
Requests per second: 47019.38 [#/sec]
Transfer rate: 48467.57 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.0 0.3 54.1 0.2
Percentage of the requests served within a certain time (ms)
50% 0.3 ms
90% 0.4 ms
98% 0.6 ms
99% 0.7 ms
100% 54.1 ms
make benchmark
warp: Benchmark data written to "warp-mixed-2023-10-16[102354]-l70a.csv.zst"
Mixed operations.
Operation: DELETE, 10%, Concurrency: 20, Ran 4m59s.
* Throughput: 6.19 obj/s
Operation: GET, 45%, Concurrency: 20, Ran 5m0s.
* Throughput: 279.85 MiB/s, 27.99 obj/s
Operation: PUT, 15%, Concurrency: 20, Ran 5m0s.
* Throughput: 89.86 MiB/s, 8.99 obj/s
Operation: STAT, 30%, Concurrency: 20, Ran 5m0s.
* Throughput: 18.63 obj/s
Cluster Total: 369.74 MiB/s, 61.79 obj/s, 0 errors over 5m0s.
Чтобы просмотреть статистику сегментированных запросов, используйте параметр --analyze.v.
warp analyze --analyze.v warp-mixed-2023-10-16[102354]-l70a.csv.zst
18642 operations loaded... Done!
Mixed operations.
----------------------------------------
Operation: DELETE - total: 1854, 10.0%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 6.19 obj/s
Requests considered: 1855:
* Avg: 104ms, 50%: 30ms, 90%: 207ms, 99%: 1.355s, Fastest: 1ms, Slowest: 4.613s, StdDev: 320ms
----------------------------------------
Operation: GET - total: 8388, 45.3%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.12 +0500 +05
* Throughput: 279.77 MiB/s, 27.98 obj/s
Requests considered: 8389:
* Avg: 221ms, 50%: 106ms, 90%: 492ms, 99%: 1.739s, Fastest: 8ms, Slowest: 8.633s, StdDev: 383ms
* TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 171ms, 99th: 669ms, Worst: 4.783s StdDev: 163ms
* First Access: Avg: 240ms, 50%: 105ms, 90%: 511ms, 99%: 2.08s, Fastest: 12ms, Slowest: 8.633s, StdDev: 480ms
* First Access TTFB: Avg: 88ms, Best: 2ms, 25th: 24ms, Median: 38ms, 75th: 64ms, 90th: 179ms, 99th: 919ms, Worst: 4.783s StdDev: 199ms
* Last Access: Avg: 219ms, 50%: 106ms, 90%: 463ms, 99%: 1.782s, Fastest: 9ms, Slowest: 8.633s, StdDev: 416ms
* Last Access TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 161ms, 99th: 657ms, Worst: 4.783s StdDev: 176ms
----------------------------------------
Operation: PUT - total: 2688, 14.5%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 89.83 MiB/s, 8.98 obj/s
Requests considered: 2689:
* Avg: 1.165s, 50%: 878ms, 90%: 2.015s, 99%: 5.74s, Fastest: 99ms, Slowest: 8.264s, StdDev: 968ms
----------------------------------------
Operation: STAT - total: 5586, 30.2%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.113 +0500 +05
* Throughput: 18.63 obj/s
Requests considered: 5587:
* Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 80ms, Fastest: 0s, Slowest: 245ms, StdDev: 17ms
* First Access: Avg: 14ms, 50%: 10ms, 90%: 33ms, 99%: 69ms, Fastest: 0s, Slowest: 203ms, StdDev: 16ms
* Last Access: Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 74ms, Fastest: 0s, Slowest: 203ms, StdDev: 17ms
Cluster Total: 369.64 MiB/s, 61.77 obj/s, 0 errors over 5m0s.
Total Errors:0.
Вернуться к оглавлению
Лицензия Apache версии 2.0 («Лицензия»); вы не можете использовать этот файл, кроме как в соответствии с Лицензией. Вы можете получить копию Лицензии по адресу:
http://www.apache.org/licenses/LICENSE-2.0
Если это не требуется действующим законодательством или не согласовано в письменной форме, программное обеспечение, распространяемое по Лицензии, распространяется на условиях «КАК ЕСТЬ», БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ ИЛИ УСЛОВИЙ, явных или подразумеваемых. См. Лицензию для определения конкретного языка, регулирующего разрешения и ограничения в рамках Лицензии.
Текст этой страницы доступен для изменения и повторного использования в соответствии с условиями непортированной лицензии Creative Commons Attribution-Sharealike 3.0 и лицензии GNU Free Documentation License (неверсированной, без неизменяемых разделов, текстов на передней обложке или текстов на задней обложке).
Вернуться к оглавлению
