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는 Facebook의 Haystack 디자인 페이퍼를 구현하면서 시작되었습니다. 또한 SeaweedFS는 f4의 아이디어로 삭제 코딩을 구현합니다: Facebook의 Warm BLOB Storage System은 Facebook의 Tectonic Filesystem과 많은 유사점을 가지고 있습니다.
객체 저장소 외에도 선택적 Filer는 디렉토리 및 POSIX 속성을 지원할 수 있습니다. Filer는 MySql, Postgres, Redis, Cassandra, HBase, Mongodb, Elastic Search, LevelDB, RocksDB, Sqlite, MemSql, TiDB, Etcd, CockroachDB, YDB 등과 같은 사용자 정의 가능한 메타데이터 저장소를 갖춘 별도의 선형 확장이 가능한 상태 비저장 서버입니다.
분산된 키 값 저장소의 경우 큰 값을 SeaweedFS로 오프로드할 수 있습니다. 빠른 액세스 속도와 선형적으로 확장 가능한 용량을 갖춘 SeaweedFS는 분산된 Key-Large-Value 저장소로 작동할 수 있습니다.
SeaweedFS는 클라우드와 투명하게 통합될 수 있습니다. SeaweedFS는 로컬 클러스터의 핫 데이터와 O(1) 액세스 시간의 클라우드상의 웜 데이터를 통해 빠른 로컬 액세스 시간과 탄력적인 클라우드 스토리지 용량을 모두 달성할 수 있습니다. 또한 클라우드 스토리지 액세스 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"}
둘째, 파일 콘텐츠를 저장하려면 응답에서 url + '/' + fid 에 HTTP 다중 부분 POST 요청을 보냅니다.
> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}
업데이트하려면 업데이트된 파일 콘텐츠가 포함된 또 다른 POST 요청을 보내세요.
삭제하려면 동일한 url + '/' + fid URL로 HTTP DELETE 요청을 보냅니다.
> curl -X DELETE http://127.0.0.1:8080/3,01637037d6
이제 이 경우 fid 3,01637037d6을 데이터베이스 필드에 저장할 수 있습니다.
시작 부분의 숫자 3은 볼륨 ID를 나타냅니다. 쉼표 뒤에는 파일 키 01과 파일 쿠키 637037d6이 있습니다.
볼륨 ID는 부호 없는 32비트 정수입니다. 파일 키는 부호 없는 64비트 정수입니다. 파일 쿠키는 URL 추측을 방지하는 데 사용되는 부호 없는 32비트 정수입니다.
파일 키와 파일 쿠키는 모두 16진수로 코딩되어 있습니다. <볼륨 ID, 파일 키, 파일 쿠키> 튜플을 원하는 형식으로 저장하거나 단순히 fid 를 문자열로 저장할 수 있습니다.
문자열로 저장하는 경우 이론적으로 8+1+16+8=33바이트가 필요합니다. 대부분의 경우 2^32 볼륨이 필요하지 않으므로 char(33)이면 충분합니다.
공간이 정말 걱정된다면 파일 ID를 원하는 형식으로 저장할 수 있습니다. 볼륨 ID에는 4바이트 정수 하나, 파일 키에는 8바이트 긴 숫자, 파일 쿠키에는 4바이트 정수가 필요합니다. 따라서 16바이트이면 충분합니다.
다음은 URL을 렌더링하는 방법의 예입니다.
먼저 파일의 VolumeId로 볼륨 서버의 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는 볼륨 수준에서 복제 전략을 적용합니다. 따라서 파일 ID를 얻을 때 복제 전략을 지정할 수 있습니다. 예를 들어:
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는 마스터 서버의 데이터 볼륨을 관리합니다. 각 데이터 볼륨의 크기는 32GB이며 많은 파일을 저장할 수 있습니다. 그리고 각 스토리지 노드에는 많은 데이터 볼륨이 있을 수 있습니다. 따라서 마스터 노드는 볼륨에 대한 메타데이터만 저장하면 되는데, 이는 상당히 적은 양의 데이터이고 일반적으로 안정적입니다.
실제 파일 메타데이터는 볼륨 서버의 각 볼륨에 저장됩니다. 각 볼륨 서버는 각 파일당 16바이트만 사용하여 자체 디스크에 있는 파일의 메타데이터만 관리하므로 모든 파일 액세스는 메모리에서 파일 메타데이터를 읽을 수 있으며 실제로 파일 데이터를 읽으려면 한 번의 디스크 작업만 필요합니다.
비교를 위해 Linux의 xfs inode 구조가 536바이트라는 점을 고려하세요.
아키텍처는 매우 간단합니다. 실제 데이터는 스토리지 노드의 볼륨에 저장됩니다. 하나의 볼륨 서버는 여러 볼륨을 가질 수 있으며 기본 인증을 통해 읽기 및 쓰기 액세스를 모두 지원할 수 있습니다.
모든 볼륨은 마스터 서버에서 관리됩니다. 마스터 서버에는 볼륨 서버 매핑에 대한 볼륨 ID가 포함되어 있습니다. 이는 상당히 정적인 정보이므로 쉽게 캐시할 수 있습니다.
각 쓰기 요청에서 마스터 서버는 또한 점점 증가하는 64비트 부호 없는 정수인 파일 키를 생성합니다. 일반적으로 쓰기 요청은 읽기 요청만큼 빈번하지 않기 때문에 하나의 마스터 서버가 동시성을 잘 처리할 수 있어야 합니다.
클라이언트가 쓰기 요청을 보내면 마스터 서버는 파일에 대한 (볼륨 ID, 파일 키, 파일 쿠키, 볼륨 노드 URL)을 반환합니다. 그런 다음 클라이언트는 볼륨 노드에 접속하고 파일 콘텐츠를 게시합니다.
클라이언트가 (볼륨 ID, 파일 키, 파일 쿠키)를 기반으로 파일을 읽어야 하는 경우 마스터 서버에 볼륨 ID로 (볼륨 노드 URL, 볼륨 노드 공용 URL)을 요청하거나 이를 캐시에서 검색합니다. 그런 다음 클라이언트는 콘텐츠를 가져오거나 웹 페이지에 URL을 렌더링하고 브라우저가 콘텐츠를 가져오도록 할 수 있습니다.
쓰기-읽기 프로세스에 대한 자세한 내용은 예제를 참조하세요.
현재 구현에서는 각 볼륨이 32기비바이트(32GiB 또는 8x2^32바이트)를 보유할 수 있습니다. 이는 콘텐츠를 8바이트로 정렬하기 때문입니다. 정렬로 인해 패딩 공간이 낭비되는 대신 두 줄의 코드를 변경하여 이를 64GiB 또는 128GiB 이상으로 쉽게 늘릴 수 있습니다.
볼륨은 4기비바이트(4GiB 또는 2^32바이트)일 수 있습니다. 따라서 전체 시스템 크기는 8 x 4GiB x 4GiB, 즉 128엑비바이트(128EiB 또는 2^67바이트)입니다.
각 개별 파일 크기는 볼륨 크기로 제한됩니다.
볼륨 서버에 저장된 모든 파일 메타 정보는 디스크 액세스 없이 메모리에서 읽을 수 있습니다. 각 파일은 <64비트 키, 32비트 오프셋, 32비트 크기>의 16바이트 맵 항목만 사용합니다. 물론 각 지도 항목에는 지도에 대한 자체 공간 비용이 있습니다. 그러나 일반적으로 메모리가 부족하기 전에 디스크 공간이 부족해집니다.
로컬 볼륨 서버는 훨씬 더 빠른 반면, 클라우드 스토리지는 탄력적인 용량을 가지며 자주 액세스하지 않으면 실제로 비용 효율적입니다(대개 업로드는 무료이지만 액세스 비용은 상대적으로 비쌉니다). 추가 전용 구조와 O(1) 액세스 시간을 통해 SeaweedFS는 웜 데이터를 클라우드로 오프로드하여 로컬 및 클라우드 스토리지를 모두 활용할 수 있습니다.
일반적으로 핫 데이터는 최신 데이터이고 웜 데이터는 오래된 데이터입니다. SeaweedFS는 새로 생성된 볼륨을 로컬 서버에 배치하고 선택적으로 이전 볼륨을 클라우드에 업로드합니다. 오래된 데이터에 자주 액세스하지 않는 경우 말 그대로 제한된 로컬 서버로 무제한의 용량을 제공하면서도 새로운 데이터에 대해서는 여전히 빠른 속도를 제공합니다.
O(1) 액세스 시간을 사용하면 네트워크 대기 시간 비용이 최소로 유지됩니다.
핫/웜 데이터를 20/80으로 분할하면 20대의 서버로 100대의 서버 저장 용량을 확보할 수 있습니다. 이는 80%의 비용 절감 효과입니다! 또는 80개 서버의 용도를 변경하여 새로운 데이터도 저장하고 스토리지 처리량을 5배 높일 수 있습니다.
목차로 돌아가기
대부분의 다른 분산 파일 시스템은 필요 이상으로 복잡해 보입니다.
SeaweedFS는 설정과 작동 모두에서 빠르고 간단합니다. 여기에 도달했을 때 어떻게 작동하는지 이해하지 못한다면 우리는 실패한 것입니다! 질문이 있는 경우 문제를 제기하거나 설명을 포함하여 이 파일을 업데이트하세요.
SeaweedFS는 끊임없이 전진하고 있습니다. 다른 시스템과 동일합니다. 이러한 비교는 빠르게 구식이 될 수 있습니다. 최신 상태로 유지하도록 도와주세요.
목차로 돌아가기
HDFS는 각 파일에 대해 청크 접근 방식을 사용하며 대용량 파일을 저장하는 데 이상적입니다.
SeaweedFS는 상대적으로 작은 파일을 빠르고 동시에 제공하는 데 이상적입니다.
SeaweedFS는 초대형 파일을 관리 가능한 데이터 청크로 분할하여 저장할 수도 있고, 데이터 청크의 파일 ID를 메타 청크로 저장할 수도 있습니다. 이는 "잡초 업로드/다운로드" 도구로 관리되며, 잡초 마스터 또는 볼륨 서버는 이에 대해 불가지론적입니다.
목차로 돌아가기
아키텍처는 대부분 동일합니다. SeaweedFS는 단순하고 평면적인 아키텍처로 파일을 빠르게 저장하고 읽는 것을 목표로 합니다. 주요 차이점은 다음과 같습니다.
| 체계 | 파일 메타데이터 | 파일 콘텐츠 읽기 | POSIX | REST API | 다수의 작은 파일에 최적화됨 |
|---|---|---|---|---|---|
| 해초FS | 조회 볼륨 ID, 캐시 가능 | O(1) 디스크 탐색 | 예 | 예 | |
| 해초FS 파일러 | 선형 확장 가능, 사용자 정의 가능 | O(1) 디스크 탐색 | 퓨즈 | 예 | 예 |
| GlusterFS | 해싱 | 퓨즈, NFS | |||
| 세프 | 해싱 + 규칙 | 퓨즈 | 예 | ||
| 무스FS | 기억 속에 | 퓨즈 | 아니요 | ||
| 미니IO | 각 파일에 대한 별도의 메타 파일 | 예 | 아니요 |
목차로 돌아가기
GlusterFS는 "브릭"이라는 구성 가능한 볼륨에 디렉터리와 콘텐츠 파일을 저장합니다.
GlusterFS는 경로와 파일 이름을 ID로 해시하고 가상 볼륨에 할당한 다음 "브릭"에 매핑합니다.
목차로 돌아가기
MooseFS는 작은 파일 문제를 무시하기로 선택합니다. moosefs 3.0 매뉴얼에서 "작은 파일이라도 64KiB에 추가로 4KiB의 체크섬과 1KiB의 헤더를 차지합니다"라고 나와 있습니다. 왜냐하면 "처음에는 매우 큰 파일(예: 수천 개)을 대량으로 보관하기 위해 설계되었기 때문입니다."
MooseFS 마스터 서버는 모든 메타데이터를 메모리에 보관합니다. HDFS 네임노드와 동일한 문제입니다.
목차로 돌아가기
Ceph는 SeaweedFS와 유사하게 키->BLOB 저장소로 설정할 수 있습니다. 그 위에 레이어를 지원해야 하므로 훨씬 더 복잡합니다. 좀 더 자세한 비교는 이렇습니다
SeaweedFS에는 여유 볼륨을 조회하기 위한 중앙 집중식 마스터 그룹이 있는 반면 Ceph는 해싱 및 메타데이터 서버를 사용하여 객체를 찾습니다. 중앙 집중식 마스터를 사용하면 코딩 및 관리가 쉬워집니다.
SeaweedFS와 마찬가지로 Ceph는 객체 저장소 RADOS를 기반으로 합니다. Ceph는 리뷰가 엇갈려 다소 복잡합니다.
Ceph는 CRUSH 해싱을 사용하여 데이터 배치를 자동으로 관리하므로 데이터를 찾는 데 효율적입니다. 하지만 데이터는 CRUSH 알고리즘에 따라 배치되어야 합니다. 잘못된 구성으로 인해 데이터가 손실될 수 있습니다. 용량을 늘리기 위해 새 서버를 추가하는 등의 토폴로지 변경으로 인해 CRUSH 알고리즘에 맞게 높은 IO 비용으로 데이터 마이그레이션이 발생합니다. SeaweedFS는 쓰기 가능한 볼륨에 데이터를 할당하여 배치합니다. 한 볼륨에 대한 쓰기가 실패한 경우 쓸 다른 볼륨을 선택하면 됩니다. 더 많은 볼륨을 추가하는 것도 가능한 한 간단합니다.
SeaweedFS는 작은 파일에 최적화되어 있습니다. 작은 파일은 하나의 연속적인 콘텐츠 블록으로 저장되며, 파일 간 최대 8바이트는 사용되지 않습니다. 작은 파일 액세스는 O(1) 디스크 읽기입니다.
SeaweedFS Filer는 MySql, Postgres, Sqlite, Mongodb, Redis, Elastic Search, Cassandra, HBase, MemSql, TiDB, CockroachCB, Etcd, YDB와 같은 기성 저장소를 사용하여 파일 디렉터리를 관리합니다. 이러한 매장은 검증되고 확장 가능하며 관리하기 쉽습니다.
| 해초FS | 세프와 비슷하다 | 이점 |
|---|---|---|
| 주인 | MDS | 더 간단하다 |
| 용량 | OSD | 작은 파일에 최적화 |
| 파일러 | 세프 FS | 선형 확장 가능, 사용자 정의 가능, O(1) 또는 O(logN) |
목차로 돌아가기
MinIO는 AWS S3를 밀접하게 따르며 S3 API 테스트에 이상적입니다. UI, 정책, 버전 관리 등이 좋습니다. SeaweedFS는 여기서 따라잡으려고 노력하고 있습니다. 나중에 MinIO를 SeaweedFS 앞에 게이트웨이로 배치하는 것도 가능합니다.
MinIO 메타데이터는 단순 파일에 있습니다. 각 파일 쓰기에는 해당 메타 파일에 대한 추가 쓰기가 발생합니다.
MinIO에는 많은 작은 파일에 대한 최적화 기능이 없습니다. 파일은 로컬 디스크에 있는 그대로 저장됩니다. 게다가 삭제 코딩을 위한 추가 메타 파일과 샤드는 LOSF 문제를 증폭시킬 뿐입니다.
MinIO에는 하나의 파일을 읽기 위한 여러 디스크 IO가 있습니다. 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.git3단계: 다음 명령을 실행하여 프로젝트를 다운로드, 컴파일 및 설치합니다.
cd seaweedfs/weed && make install 이 작업이 완료되면 $GOPATH/bin 디렉토리에서 실행 가능한 "weed"를 찾을 수 있습니다.
목차로 돌아가기
SeaweedFS에서 읽기 성능을 테스트하면 기본적으로 하드 드라이브의 임의 읽기 속도에 대한 성능 테스트가 됩니다. 하드 드라이브는 일반적으로 100MB/s~200MB/s를 얻습니다.
작은 파일을 수정하거나 삭제하려면 SSD는 한 번에 전체 블록을 삭제하고 기존 블록의 콘텐츠를 새 블록으로 이동해야 합니다. SSD는 새 제품일 때는 빠르지만 시간이 지남에 따라 단편화되고 가비지 수집을 통해 블록을 압축해야 합니다. SeaweedFS는 추가 전용이므로 SSD에 적합합니다. 삭제 및 압축은 백그라운드의 볼륨 수준에서 수행되므로 읽기 속도가 느려지거나 조각화가 발생하지 않습니다.
목차로 돌아가기
SSD(Solid State Disk), CPU: Intel Core i7 2.6GHz 1개를 장착한 Mac Book에서 나만의 비과학적인 단일 시스템 결과.
1백만 개의 1KB 파일 쓰기:
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 Unported License 및 GNU Free Documentation License(버전 없음, 불변 섹션, 앞 표지 텍스트 또는 뒷 표지 텍스트 없음)의 조건에 따라 수정 및 재사용이 가능합니다.
목차로 돌아가기
