Kitsune2: 조회가 251배 빠르고, 업데이트 경로가 33배, 그리고 가십이 15배 더 빨리 시작됩니다
Holochain의 네트워킹 레이어에서의 아침 실험: 노드가 피어를 찾고, 누락된 데이터를 가져오며, 가십을 재개하고, 그리고 6 작은 패치가 그 과정에서 어떻게 변했는지.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
나는 최근 4:30 a.m.에 일어나서 해가 뜨기 직전에 일어나서 그것을 즐기고 있습니다. 9월 19일, 나는 그 아침을 Kitsune2에 대한 실험실을 시작하는 데 사용했고, Holochain 아래의 피어-투-피어 네트워킹 레이어가 어디에 시간을 쓰는지 찾으려 했습니다.12:20 p.m.까지 실험실은 6개의 패치를 만들었습니다. 엔드포인트 조회: 251× 빠름 10,000 보존된 ID에서. 그들을 호출하는 피어-업데이트 경로: 33× 빠름. 완성된 페치 후 가십 시작: 3,002 ms에서 202 ms로 감소. 버스트 요청 트래픽: 96.9% 더 적은 메시지. 3는 불필요하게 기다리거나 결코 일어나지 않을 일을 기다리던 작업을 수리했습니다.나는 25년 이상 코딩을 해왔고 GPT-3 이후로 AI와 함께 구축해 왔습니다. 나는 그것을 사용해 내가 관심 있는 것이나 아직 이해하지 못한 것을 분리하고, 그것을 해결하며, 우리가 배웠다고 생각하는 것을 테스트합니다. 나는 그 부분을 좋아합니다: 질문을 실험으로 바꾸고 무엇이 유지되는지 보는 것. 오늘 아침, AI 코딩 에이전트와 함께, 나는 Holochain 노드가 서로를 최신 상태로 유지하도록 하는 메커니즘에 그 접근법을 적용했습니다.Holochain 애플리케이션은 참여 컴퓨터, 즉 노드들 간에 데이터를 공유합니다. 각 참가자는 자신의 서명된 기록을 보관하고 애플리케이션의 공유 데이터 일부를 검증하고 저장하는 데 도움을 줍니다. 그 공유 저장소는 분산 해시 테이블(distributed hash table, DHT)입니다. 복사본은 여러 피어와 함께 존재하므로, 작성자가 오프라인이 되어도 데이터는 계속 이용 가능합니다. Holochain's DHT guide는 이러한 책임이 어떻게 분산되는지 설명합니다.Kitsune2는 이 아래에서 피어 투 피어 통신을 처리합니다. 노드가 동기화되는 상황을 상상해 보세요: 노드는 피어가 어디에 있는지 학습하고, 자신이 보유한 것과 피어가 보유한 것을 비교하며, 부족한 조각을 요청합니다. Gossip은 피어가 차이점을 발견하는 교환 방식이며, fetch는 누락된 연산을 가져오고, Kitsune2가 전송하는 데이터 단위입니다. 수신 노드는 이를 호스트의 연산 저장소에 전달합니다. Holochain은 그 검증과 통합을 처리합니다.Diagram source
graph TD
A[피어 ID와 엔드포인트를 학습합니다] --> B[Gossip을 통해 데이터를 비교합니다]
B --> C[누락된 연산을 식별합니다]
C --> D[피어로부터 연산을 가져옵니다]
D --> E[수신된 연산을 호스트 저장소에 전달합니다]
E --> F[보류 중인 fetch가 완료되었음을 신호합니다]
F e1@--> B
e1@{ animation: fast }
Copy source패치는 그 순서에 따라 배치됩니다. 일부는 노드가 수행하는 작업을 줄이고, 다른 일부는 작업이 이미 끝났을 때 진행하도록 합니다. 위의 수치는 로컬 테스트 노드에서 해당 단계들을 측정한 것입니다.
우리는 상류 커밋 06555ee에서 시작점을 고정했고, 개발 소스는 0.6.0-dev.1이다. 각 비교는 그 기준선과 기록된 패치 시퀀스를 사용한다. 아래 라벨은 발견을 우리의 실험 기록과 연결한다; 모든 6 패치는 이제 상류 검토를 위해 제출되었다.
라벨
변경 내용
측정 결과
K3a
가져오기가 완료되면 기존 드레인 헬퍼를 호출한다
완료된 가져오기 후 Gossip 시작: 3,002 → 202 ms
K3b
수신자 락을 디큐에 스코프한다
실제 동시성은 1였다. 구성된 워커는 이제 실제로 겹친다
K3c
Generation-tagged 입장 소유권
취소된 호출자 스트랜드 0 대기 키. 기준선 스트랜드는 8
K3d-P1
Set 기반 응답 정리
1.9–6.1× 대규모 대기 부하에서 더 빠른 응답 처리
K3d-P2
같은 피어 배치 선택 (기본 1)
버스트: 87.5–96.9% 요청 메시지 감소
K1
URL을 에이전트 인덱스로 역전
10,000 보존된 ID: 업데이트 21–33×, 조회 118–251× 가속, 3.10× 저장 메모리
첫 번째 수리 재연결은 fetch 완료를 대기 중인 gossip 작업에 연결합니다. 변경 사항은 대기 중인 맵이 비워졌음을 리스너에게 알리는 기존 헬퍼를 호출합니다. 우리는 완료된 fetch와 의도적으로 열려 있는 fetch를 모두 테스트했습니다.
Gossip initiation after a fetch completes, with the control that must not move (ms)Chart data
milliseconds
Upstream 06555ee
With the drain notification restored
Fetch completed
3001
202
Fetch still pending (control)
3002
3001
완료 후 gossip은 진행될 수 있습니다. fetch가 대기 중인 동안 두 버전 모두 여전히 폴백 타이머에 도달합니다. 위의 격리 테스트는 3,001 → 202 ms를 측정했으며, 이후 결합 재생은 3,002 → 202 ms를 측정했습니다. 두 경우 모두 3,000 ms 폴백과 200 ms 초기 지연을 사용했습니다. 대략 15× 차이는 작업이 폴백을 기다렸는지 완료 시 깨어났는지를 기록합니다.
Rust 크레이트는 코드 패키지이다. 모든 6 패치는 코어 크레이트에 있으며, 여기에는 피어 기록과 페치 기계가 포함되어 있다. 그들은 gossip 알고리즘이나 기본 네트워크 전송을 편집하지 않고 gossip이 데이터를 받고 완료 신호를 받는 방식을 바꾼다. 배칭은 선택적 코어 구성 필드를 추가한다.
라벨
파일
라인
K1
core/src/factories/core_known_peers.rs
+33 / −10
K3a
core/src/factories/core_fetch.rs
+1
K3b
core/src/factories/core_fetch.rs
+11 / −3
K3c
core/src/factories/core_fetch.rs
+71 / −53
K3d-P1
core/src/factories/core_fetch.rs
+6 / −1
K3d-P2
core/src/factories/core_fetch.rs, 1 테스트 파일
+89 / −17
5 패치가 core_fetch.rs에 기록된 순서대로 쌓여 있으며, 누락된 작업을 요청하고 응답을 처리합니다. 남은 패치는 core_known_peers.rs에 있으며, 어느 정체성이 어느 네트워크 엔드포인트와 연결되어 있는지 보존된 기록입니다. 그런 다음 모든 6를 단일 소스 트리에 적용하고 함께 실행했습니다.
CoreFetch는 요청한 작업과 그 출처를 매핑해 둡니다. 피어의 응답이 도착하고 작업이 성공적으로 저장되면, 코드는 해당 식별자를 매핑에서 제거합니다. 파일의 다른 부분, send-error 경로 및 피어 정리 경로는 항목을 제거한 직후 notify_listeners_if_queue_drained라는 헬퍼를 호출합니다. 성공 경로는 절대로 호출하지 않았습니다.노드는 저장하는 DHT의 일부를 확장할 수 있으며, 이를 storage arc라고 부릅니다. 이를 위해서는 더 큰 범위 내의 데이터를 따라잡아야 합니다. arc‑growth 경로에서 우리는 gossip이 피어와 시작하기 전에 미결 fetch를 모두 끝내도록 기다리며, 타이머를 대체로 사용하도록 테스트했습니다. 데이터가 도착하고 보류 중인 매핑이 비워졌지만, 해당 신호를 기다리는 작업은 타이머가 만료될 때까지 잠자기 상태를 유지했습니다.Diagram source
sequenceDiagram
participant G as Gossip arc-growth loop
participant F as CoreFetch
participant P as Peer
G->>F: Register a drain waiter
P->>F: Final response, operations stored
F->>F: retain() empties the pending map
Note over F: helper exists, never called
F--xG: Notification that never arrives
G->>G: Initiate after the roughly 3-second fallback
Copy source완료 후 확인하면 차이가 사라집니다: 새로 등록된 대기자는 빈 매핑을 보고 즉시 반환합니다. 우리는 우리 것을 등록했습니다 이전 완료. 데이터가 저장되자 그 웨이터는 원래 코드에 알림이 없었지만 패치를 적용하면 알림을 받았습니다. 이는 데이터 수신과 다음 가십 교환 시작 사이의 핸드오프를 수리합니다.우리는 또한 부분 응답, 저장 오류, 여러 리스너, 요청이 완료되거나 새로운 작업이 도착했을 때 리스너가 등록되는 것을 확인했습니다. 부분 응답은 웨이터를 보류 상태로 두어야 하며, 최종 미결제 가져오기가 완료될 때만 깨어나야 합니다.
CoreFetch 의 아웃고잉 측은 하나의 공유 채널에서 끌어오는 구성된 수의 워커 작업을 실행한다. 루프는 다음과 같이 작성되었다:rustCopy source
while let Some(..) = outgoing_request_rx.lock().await.recv().await { // send the request}
잠금은 1 워커가 공유 큐에서 다음 요청을 가져가도록 한다. 그러나 Rust 은 이 while let 의 본문 전체에 걸쳐 임시 잠금 보호를 유지하며, 네트워크 전송 대기까지 포함한다. 1 워커가 전송 중일 때, 다른 4 는 다음 요청을 수집할 수 없었다. 모든 요청은 결국 도착할 수 있었으므로, 구성된 동시성은 사용되지 않은 채로도 전달 테스트가 통과할 수 있었다.우리는 수신을 짧은 블록으로 옮겨 잠금이 전송이 시작되기 전에 해제되도록 했다. 워커는 여전히 번갈아 가며 요청을 수집한 뒤 동시에 전송한다. 느린 전송은 더 이상 다른 워커가 요청을 준비해 두었을 때 큐 잠금을 보유하지 않는다.
Outgoing sends in flight at the same moment, by configured worker countChart data
concurrent sends observed
Upstream 06555ee
Dequeue-scoped guard
1 worker
1
1
2 workers
1
2
5 workers
1
5
측정은 각 전송을 일시 정지된 시계와 함께 열어 두고, 어떤 것이 해제되기 전에 몇 개가 들어왔는지 세며, 구성된 한계를 넘어서는 것이 없음을 확인한다.
가져오기 요청은 2 레코드를 통해 전달됩니다: 보류 중인 맵은 노드가 무엇을 기다리고 있는지 말해 주고, 나가는 큐는 전송 작업자용 작업을 보유합니다. request_ops, 작업을 요청하는 메서드는 해당 큐에 공간이 있을 때까지 기다리기 전에 보류 중인 맵에 전체 배치를 추가했습니다.호출자가 용량을 기다리는 동안 취소되면, 일부 작업은 이미 보류 중으로 표시되었지만, 어떤 작업자도 이를 수신하지 않았습니다. 우리는 큐를 채우고, 차단된 호출자를 취소하고, 모든 16,385 승인된 요청이 완료되도록 했습니다. 8 작업은 보류 중이었습니다. 그들은 나가는 큐에 들어가지 않았으므로, 이를 정리할 응답이 없었습니다.이는 첫 번째 수리와 직접 연결됩니다: 맵에 아직 완료되지 않은 작업이 남아 있는 동안 완료 알림은 발생할 수 없습니다. 여기서 노드 자체의 회계가 그를 기다리게 했습니다.패치는 먼저 큐 용량을 예약한 다음, 그 사이에 다른 await 없이 작업을 기록하고 큐에 넣습니다. 각 항목은 세대 태그도 함께 전달하므로, 이전에 실패한 전송의 정리가 동일 작업에 대한 새 요청을 지울 수 없습니다. 이미 승인된 작업은 호출자의 취소에도 살아남습니다; 승인 대기 중인 작업은 보류 중인 항목을 남기지 않습니다.이는 요청의 소유권을 수리합니다. 총 메모리 제한은 별도의 설계 질문으로 남아 있습니다, 호출자가 여전히 큰 배치를 제공할 수 있기 때문입니다.
따라잡는 노드는 같은 피어에서 많은 작업이 필요할 수 있습니다. Kitsune2의 요청 형식은 이미 식별자 목록을 지원하지만, 나가는 코드는 메시지당 1를 보냅니다. 이러한 요청을 결합하기 전에, 우리는 더 큰 응답이 어떻게 처리될지 확인했습니다.보류 중인 각 작업에 대해, 응답 정리는 반환된 식별자 목록을 스캔하여 해당 항목을 제거할 수 있는지 확인했습니다. 8,192 보류 중인 항목과 1,024 반환된 식별자가 있으면, 이는 많은 검색을 반복합니다. 반환된 식별자의 HashSet를 구축하면 각 멤버십 검사가 저렴해집니다; 그 경우 응답 처리는 6.1× 빠르게 측정되었습니다. 반환된 식별자가 16만 있을 때, 데이터를 저장하는 것이 지배적이었고 변화는 거의 없었습니다.그런 다음 우리는 같은 피어에 대한 준비된 요청을 결합했습니다. 64개의 작은 작업이 폭발적으로 발생할 때, 8와 32의 배치 크기는 요청 메시지를 각각 87.5%와 96.9%만큼 줄였습니다.
Burst behaviour relative to the default batch size of 1 (percent of control)Chart data
percent of control
Request messages
Elapsed time
Batch 1 (control)
100
105.4
Batch 8
12.5
72.6
Batch 32
3.1
67.7
폭발은 약 27–32%만큼 일찍 끝났습니다. 같은 작업은 여전히 전송되고 저장되어야 했으며, 절약은 얼마나 많은 요청이 그것들을 담았는가에 있었습니다. 배치-1 제어는 기준 경과 시간을 105.4% 측정했으며, 배치가 비활성화되어도 대략 5% 타이밍 드리프트를 보여주었습니다.작업자는 이미 준비된 요청만 결합하므로, 단독 요청은 배치가 채워질 때까지 기다리지 않습니다. 배치 분할은 구성된 식별자 한계와 4,096-바이트 인코딩된 요청 임계값을 모두 사용합니다. 항목 수만 세는 것은 총 크기를 제한하지 않습니다; 200 식별자 테스트는 이를 여러 제한된 메시지로 분할합니다. 단일 식별자는 그 자체가 임계값을 초과하면 여전히 전송됩니다, 따라서 이것은 보편적인 와이어 크기 한계가 아닙니다. 응답은 실제 데이터를 전달하며, 응답 노드에 별도의 크기 제한이 필요합니다.후보자는 배치 크기를 1를 기본값으로 유지하고 기존 구성을 그대로 수용합니다. 별도의 테스트가 일관되지 않은 꼬리 지연 결과를 초래했기 때문에 더 큰 배치를 선택하도록 남겨 두었습니다. 아래에서 자세히 다룹니다.
업데이트 경로에서 스캔을 제거하는 것이 33배, 조회 자체에서 251배의 이점을 제공했습니다#
CoreKnownPeers는 정체성과 그와 연결된 네트워크 엔드포인트를 기억합니다. 여러 정체성이 하나의 엔드포인트를 공유할 수 있으며, 차단된 정체성은 활성 피어 저장소에서 제거된 후에도 식별 가능해야 합니다. 10,000 보존된 정체성은 이 저장소에 있는 정체성의 이력을 의미하며, 동시에 연결된 10,000 컴퓨터를 의미하지는 않습니다.피어 저장소가 업데이트될 때, 접근 제어는 엔드포인트에 속하는 정체성을 묻습니다. 조회, get_by_url, 는 매번 잠금 하에 전체 보존된 맵을 스캔했습니다. 그 이력이 커지면서 현재 피어 정보를 업데이트하는 비용이 증가했습니다.우리는 엔드포인트 URL에서 해당 엔드포인트와 연결된 정체성으로의 인덱스를 추가했습니다: HashMap<Url, HashSet<AgentId>>. 원본 레코드는 여전히 권위적입니다. 정체성이 엔드포인트를 변경하면, 인덱스는 해당 세트로 이동합니다; 조회는 그 세트로 직접 이동할 수 있습니다. 두 버전 모두 업데이트, 오래된 광고, 제거 및 공유 엔드포인트를 포함한 19,422 결과 검사를 통과했습니다.
Microseconds per 16-advertisement update call (log scale)Chart data
microseconds per update call
retained identities
Upstream linear scan
Derived URL index
100
6.857
4.911
1,000
18.103
4.774
10,000
154.849
4.72
위의 각 타임드 호출은 16 광고를 삽입하고 접근 제어 리스너를 실행합니다. 10,000 보존된 정체성에서, 약 155 µs에서 4.72 µs로 감소했으며, 이는 33배의 이득을 의미합니다. 인덱스 버전은 이 크기 범위에서 거의 평평하게 유지됩니다. 이는 리스너가 더 이상 증가하는 이력을 스캔하지 않기 때문입니다.API에서 측정한 결과, 호출자를 통해가 아니라 조회 자체가 스캔에서 해시로 전환됩니다. 10,000 보존된 정체성에서의 미스는 11,423 ns에서 45 ns로 감소했으며, 이는 251배이며, 단일 히트는 9,309 ns에서 79 ns로 감소했으며, 118배입니다. 많은 정체성을 반환하는 쿼리는 반환되는 양에 따라 확장되므로, 공유-URL 사례는 2계수의 차이보다 4.4배의 이득을 얻습니다. 251배는 고립된 조회 결과입니다. 33배는 이를 사용하는 더 큰 업데이트 호출을 측정한 것이며, 이러한 이득은 추가하거나 곱할 수 없습니다.
Requested store memory at 10,000 retained identities, by endpoint shapeChart data
megabytes
Upstream
With the index
Mixed endpoints
1.2
3.71
All shared
1.2
1.74
All URL-less
1.2
1.2
3.10× 혼합 스토어에서, 추가 2.51 MB가 10,000 ID에. 모든 ID가 엔드포인트를 공유하면 파생 맵이 작아지고 비용은 1.45×로 떨어집니다. ID가 URL를 갖지 않으면 파생할 것이 없고 비용은 0입니다. 이 숫자들은 보존 스토어를 위한 할당자 요청 바이트이며, 전체 노드 메모리가 아닙니다.
결합된 재생은 Kitsune2의 실제 gossip, fetch, peer-access, 메모리-스토어 구성 요소를 사용하며, 인메모리 테스트 전송을 통해 통신합니다. 우리는 원본과 패치된 소스 트리에 5 단계 시퀀스를 실행했습니다:
피어 정보 업데이트. 정체성이 엔드포인트를 변경합니다. 나중에 도착한 오래된 정보는 최신 기록을 그대로 두고, 차단된 정체성은 접근 제어를 위해 여전히 해결 가능하게 남습니다. 두 버전 모두 통과하며, 인덱스는 기존 결정을 보존합니다.
fetch가 완료된 후 gossip 시작. 패치된 노드는 202 ms 후에 시작합니다. 원본은 3,002 ms에서 대체 경로를 사용합니다.
데이터를 순서 없이 수신. 3 요청 작업은 4 응답으로 도착하며, 중복도 포함됩니다. 두 버전 모두 일관되게 저장하고 바이트 수를 올바른 작업에 연결합니다.
fetch 완료. 저장된 작업은 검색할 수 있습니다. 패치된 노드는 또한 해당 작업이 대기 중일 때 등록된 리스너를 깨웁니다.
실패한 피어 이후 계속. 제어된 전송 실패는 해당 피어의 요청 상태를 정리합니다. 다른 피어가 작업을 제공하면 대기 중인 맵이 비워지고 이후 fetch가 성공합니다. 원본에서는 완료 알림 검사가 실패합니다.
별도 상호작용 테스트는 취소와 동시 전송, 결합 배치 및 완료 알림을 결합했습니다. 수리 작업은 함께 유지되었습니다: 승인된 작업이 완료되고, 취소된 승인 항목은 고아 항목을 남기지 않으며, 리스너는 최종 응답 후 깨어났습니다.이는 데이터가 호스트 저장소에 수신되고 다음 네트워킹 단계가 진행될 수 있도록 합니다. Holochain의 검증 및 통합은 여전히 이 연구소 밖에서 진행됩니다. 이러한 변화가 실제 노드의 전체 동기화 시간을 얼마나 단축시키는지 아직 측정하지 못했습니다.
인덱스는 메모리를 차지하고 엔드포인트 변경을 더 비싸게 만듭니다. 원본 소형 저장소 테스트에서 고정된 정체성 집합을 새로운 URL로 업데이트하면 0.946× 기준 속도로 실행되었으며, 100 보존된 정체성. 10,000에서, 고립된 엔드포인트 변경 쓰기는 3.68×만큼 비용이 들었습니다. 추가 인덱스를 유지하는 데 비용이 발생합니다; 조회 절감분이 이를 상쇄해야 합니다.그 트레이드오프가 실제이므로, 인덱스가 손실되는 워크로드를 찾으려 했습니다. 36 구성을 측정 전에 사전 선언했고, 432 쌍 실행이 수행되었으며, 결과 전사본은 변형 간에 동일하게 해시되었습니다.
Paired speedup across the 36-config workload envelope, by mix (log scale)Chart data
paired speedup
retained identities
Steady, no rebind
100% rebind
Shared endpoints
URL-less heavy
100
1.61
1.47
1.42
1.09
1,000
7.2
6.26
4.12
2.13
10,000
55.56
36.42
5.55
12.16
Reference line, parity: 1
이 광범위한 매트릭스의 모든 워크로드는 중앙값이 기준을 초과했으며, 모든 수락된 업데이트가 엔드포인트를 변경하는 혼합을 포함합니다: 1.47×에서 100 정체성 및 36.42×에서 10,000. 그 업데이트는 또한 접근 제어 조회를 트리거했으며, 그 절감분이 추가 쓰기를 상쇄했습니다. 이 광범위한 워크로드는 이전 고정 집합 테스트와 다릅니다; 그 긍정적 결과는 소형 저장소 회귀를 기록에 남깁니다.100-정체성, 대부분 URL-less 사례는 결정적이지 않음: 그 1.09× 중앙값은 쌍 결과가 기준 이하를 포함했습니다. 특정 워크로드에 인덱스를 권장하기 전에 보존된 정체성 수, 엔드포인트 변경, 조회 빈도를 보여주는 실제 노드의 추적이 필요합니다.동시 전송은 정리 상호작용을 드러냈습니다. 작업자가 겹칠 수 있게 되면, 실패한 전송에 대한 정리가 다른 동일 피어에 대한 요청이 진행 중일 때 실행될 수 있었습니다. 이는 기존 피어 전체 정리를 실패한 작업보다 더 넓게 만들었습니다. 소유권 패치는 해당 요청 세대에 여전히 속한 항목으로 제거를 좁혔습니다. 패치를 함께 테스트하는 것이 여기서 중요했습니다.배칭의 단일 요청 지연은 여전히 결론이 없습니다. 우리는 p95를 측정했으며, 이 시간 안에 95%의 요청이 완료됩니다. 단독으로 전송된 요청의 경우, 작업자의 최종 실행은 1.01–1.08× 기준 p95를 보였으며, 독립 재실행은 1.44–1.58×를 보였습니다. 이 장치들은 수십 마이크로초를 걸리며, 그들의 제어도. 폭발적 개선이 재현되었지만, 단일 요청 결과는 안정되지 않아 더 큰 배치들은 opt-in 상태를 유지합니다.
우리는 또한 같은 동기화 시퀀스의 2 다른 부분을 조사했다. 둘 다 수락 가능한 패치를 생성하지 못했다.동료가 이미 보유한 것 비교 (K4). Gossip은 저장된 데이터의 압축 요약을 사용하여 차이를 찾는다. 가장 큰 테스트에서 변경되지 않은 스냅샷을 생성하고 비교하면 262,144 해시가 만들어졌다; 이를 10 번 반복해도 매번 동일한 출력을 생성했다. 이전 요약을 재사용하는 것은 매력적이지만 호스트 저장소가 신뢰할 수 있는 신호 없이 변경될 수 있어 그 저장된 결과를 무효화할 수 없다. 캐시된 요약은 그 결과로 동료 간 차이를 숨길 수 있다. 우리가 평가한 대안들도 인메모리 저장소에서 요구되는 20% 시간 절감에 미치지 못했다. 실제 Holochain 저장소의 측정값이 다음 누락된 조각이다.Gossip 전송이 정지될 때 복구 (K2). 소스를 읽으면서 전송이 잠금을 보유하고 있고 타임아웃 작업도 그 잠금을 필요로 한다는 질문이 제기되었다. 우리는 또한 그 전송이 중간에 취소되면 기본 Iroh 전송 스트림에 무슨 일이 일어나는지 확인해야 했다. 에이전트 제공자는 재현 드라이버 작업을 차단했으므로 런타임 테스트는 결코 완료되지 않았다. 이는 테스트되지 않은 우려 사항으로 남아 있으며, 패치나 신뢰성 결과가 없다.
이 실험은 개발 소스 0.6.0-dev.1에서 실행되었으며, 1개의 공유 Apple M4 Max에 16개의 논리 코어가 있었습니다. 우리는 로컬 테스트 노드와 인메모리 전송을 사용했으며, 코어 고정이나 두 번째 물리 호스트는 사용하지 않았습니다. 결과는 명명된 구성 요소와 그 상호작용을 다룹니다. 네트워크 처리량, 전체 네트워크 수렴, 총 노드 메모리, 그리고 Holochain 애플리케이션 지연은 아직 측정되지 않았습니다.이 방법은 벤치마크 기반 개발에 대한 나의 작업을 따릅니다. 우리는 각 질문과 수락 임계값을 기록하고, 각 비교 내에서 소스와 픽스처를 고정했으며, 명령, 샘플 및 실패를 append-only 영수증에 보관했습니다.3 수리용으로, 동일한 테스트는 원래 코드에서 예상된 단언에서 실패했고 패치와 함께 통과했습니다. 최적화의 경우, 두 버전 모두 동작을 보존해야 했으며, 그 다음 측정값이 명시된 임계값을 충족해야 했습니다. 타이밍 실행은 순서를 번갈아 가며, 컴파일을 측정 창 외부에 두었습니다. 감독 에이전트는 동결된 소스에서 수락 명령을 다시 실행한 뒤 각 결과를 수락했습니다; 단일 요청 지연에 대한 불일치는 최종 보고서에 남아 있습니다.완성된 패키지에는 204 영수증 디렉터리가 포함되어 있습니다. 결합 테스트는 12:17 p.m.에 수락되었으며, 터미널 결과는 12:20 p.m.에 기록되었습니다. 최종 종료 검사는 2:38 p.m.에 보관되었습니다. 모든 6개의 패치는 이제 업스트림 검토를 위해 열려 있습니다: 완료 알림, 작업자 동시성, 입학 소유권, 응답 정리, 요청 배치, 및 엔드포인트 인덱싱.
나에 의해. 연구소 자체: 내 benchmark-driven 방법, Kitsune2가 시간을 소비하는 곳을 찾도록 지시.GPT-6 Astra에 의해. 완료 알림 및 입장 소유권 수리: 진단, 패치, 그리고 원본 코드에서 실패하는 테스트. 또한 연구소 기록에서 이 기사를 다듬었습니다.GLM-5.3에 의해. 작업자 동시성 수리, 응답 정리 및 배치, 인덱스를 위한 36-구성 워크로드 행렬, 오픈 K4 질문 뒤의 DHT 요약 프로파일링, 그리고 모든 6 패치의 결합 재생.AI에 의해. 엔드포인트 인덱스와 그 측정값, 결과가 계산되기 전에 동결된 소스에서 각 수락을 재실행한 감독 에이전트, 그리고 이 기사의 초안.유지된 비판.
나에게서: 초안은 내부 메커니즘을 설명한 뒤 Holochain 노드가 무엇을 하고 있는지 말했으며, 2 오픈 질문은 아무 연결 없이 도착했습니다. 추적 시퀀스는 이제 모든 패치를 도입하고, 각 오픈 질문은 그가 관련된 단계에 놓입니다.
AI에게서: 아침이 "breakthroughs"라는 단어를 얻었는지 물었습니다. 그것은 파생 인덱스와 복원된 헬퍼 호출이 새로운 기술이 아니라 올바른 수리라고 주장했습니다. 이 기사는 발견으로 파일되었습니다.
GPT-6 Astra에게서: 몇몇 초안 주장이 영수증을 앞섰습니다. 그것은 측정된 것에 대해 그들을 평가했습니다: 10,000개의 보존된 ID는 기록이며 10,000개의 연결된 컴퓨터가 아닙니다; 인덱스의 메모리 비용은 기록에 남아 있습니다; 단일 요청 지연과 대부분 URL-less 사례는 결론이 내려지지 않았습니다.