업데이트 : 2018 년 2 월 12 일-iOS Firestore SDK v0.10.0
다른 댓글 작성자와 마찬가지로 첫 번째 get 요청에서 응답 속도가 느리다는 것을 발견했습니다 (이후 요청은 ~ 100ms 소요). 저에게는 30 대만큼 나쁘지는 않지만 연결 상태가 좋으면 2-3 초 정도가 될 수 있습니다. 앱이 시작될 때 나쁜 사용자 경험을 제공하기에 충분합니다.
Firebase는이 '콜드 스타트'문제를 알고 있으며 이에 대한 장기적인 수정 작업을 진행 중이라고 조언했습니다. 안타깝게도 ETA는 없습니다. 연결 상태가 좋지 않은 경우 요청이 캐시에서 읽기로 결정되기까지 시간이 오래 걸릴 수 있다는 것은 별도의 문제라고 생각합니다.
Firebase가 이러한 모든 문제를 해결하는 동안 저는 새로운 disableNetwork()및 enableNetwork()메서드 (Firestore v0.10.0에서 사용 가능)를 사용하여 Firebase의 온라인 / 오프라인 상태를 수동으로 제어 하기 시작했습니다 . 나는 것으로 했어하지만 매우 특정 시나리오에서 충돌이 발생할 수있는 경우 FireStore 버그 거기에 나는, 내 코드에서 사용할 경우주의하십시오.
업데이트 : 2017 년 11 월 15 일-iOS Firestore SDK v0.9.2
성능 저하 문제가 해결 된 것 같습니다. 아래에 설명 된 테스트를 다시 실행했으며 Firestore가 100 개의 문서를 반환하는 데 걸리는 시간은 이제 일관되게 약 100ms 인 것 같습니다.
이것이 최신 SDK v0.9.2의 수정인지 아니면 백엔드 수정 (또는 둘 다)인지 확실하지 않지만 모두가 Firebase 포드를 업데이트하는 것이 좋습니다. 내 앱은 실시간 DB에서와 비슷하게 눈에 띄게 더 반응이 좋습니다.
또한 특히 많은 문서를 읽을 때 Firestore가 Realtime DB보다 훨씬 느리다는 것을 발견했습니다.
업데이트 된 테스트 (최신 iOS Firestore SDK v0.9.0 포함) :
RTDB와 Firestore를 모두 사용하여 iOS Swift에서 테스트 프로젝트를 설정하고 각각에 대해 100 개의 순차적 읽기 작업을 실행했습니다. RTDB의 경우 observeSingleEvent를 테스트하고 100 개의 최상위 노드 각각에서 메소드를 관찰했습니다. Firestore의 경우 TestCol 컬렉션의 100 개 문서 각각에서 getDocument 및 addSnapshotListener 메서드를 사용했습니다. 디스크 지속성을 켜고 끄면서 테스트를 실행했습니다. 각 데이터베이스의 데이터 구조를 보여주는 첨부 이미지를 참조하십시오.
동일한 장치와 안정적인 Wi-Fi 네트워크에서 각 데이터베이스에 대해 10 번 테스트를 실행했습니다. 기존 관찰자와 청취자는 각각의 새로운 실행 전에 파괴되었습니다.
실시간 DB observeSingleEvent 메소드 :
func rtdbObserveSingle() {
let start = UInt64(floor(Date().timeIntervalSince1970 * 1000))
print("Started reading from RTDB at: \(start)")
for i in 1...100 {
Database.database().reference().child(String(i)).observeSingleEvent(of: .value) { snapshot in
let time = UInt64(floor(Date().timeIntervalSince1970 * 1000))
let data = snapshot.value as? [String: String] ?? [:]
print("Data: \(data). Returned at: \(time)")
}
}
}
실시간 DB 관찰 방법 :
func rtdbObserve() {
let start = UInt64(floor(Date().timeIntervalSince1970 * 1000))
print("Started reading from RTDB at: \(start)")
for i in 1...100 {
Database.database().reference().child(String(i)).observe(.value) { snapshot in
let time = UInt64(floor(Date().timeIntervalSince1970 * 1000))
let data = snapshot.value as? [String: String] ?? [:]
print("Data: \(data). Returned at: \(time)")
}
}
}
Firestore getDocument 메소드 :
func fsGetDocument() {
let start = UInt64(floor(Date().timeIntervalSince1970 * 1000))
print("Started reading from FS at: \(start)")
for i in 1...100 {
Firestore.firestore().collection("TestCol").document(String(i)).getDocument() { document, error in
let time = UInt64(floor(Date().timeIntervalSince1970 * 1000))
guard let document = document, document.exists && error == nil else {
print("Error: \(error?.localizedDescription ?? "nil"). Returned at: \(time)")
return
}
let data = document.data() as? [String: String] ?? [:]
print("Data: \(data). Returned at: \(time)")
}
}
}
Firestore addSnapshotListener 메소드 :
func fsAddSnapshotListener() {
let start = UInt64(floor(Date().timeIntervalSince1970 * 1000))
print("Started reading from FS at: \(start)")
for i in 1...100 {
Firestore.firestore().collection("TestCol").document(String(i)).addSnapshotListener() { document, error in
let time = UInt64(floor(Date().timeIntervalSince1970 * 1000))
guard let document = document, document.exists && error == nil else {
print("Error: \(error?.localizedDescription ?? "nil"). Returned at: \(time)")
return
}
let data = document.data() as? [String: String] ?? [:]
print("Data: \(data). Returned at: \(time)")
}
}
}
각 메서드는 기본적으로 메서드가 실행을 시작할 때 밀리 초 단위로 유닉스 타임 스탬프를 인쇄하고 각 읽기 작업이 반환 될 때 다른 유닉스 타임 스탬프를 인쇄합니다. 초기 타임 스탬프와 반환 할 마지막 타임 스탬프의 차이를 확인했습니다.
결과-디스크 지속성이 비활성화 됨 :
결과-디스크 지속성 사용 :
데이터 구조 :
Firestore getDocument / addSnapshotListener 메서드가 중단되면 대략 30 초의 배수 인 기간 동안 중단 된 것 같습니다. 아마도 이것이 Firebase 팀이 SDK에서 멈춘 부분을 분리하는 데 도움이 될 수 있습니까?
