相对于实时数据库，我在Firestore检索存储在文档中的基本数据时遇到了性能缓慢的问题，速度比例为1/10。
使用Firestore，在第一次调用时平均需要3000毫秒。
this.db.collection(‘testCol’)
.doc(‘testDoc’)
.valueChanges().forEach((data) => {
console.log(data);//3000 ms later
});
使用实时数据库，第一次调用平均需要300毫秒
this.db.database.ref(‘/test’).once(‘value’).then(data => {
console.log(data); //300ms later
});
这是网络控制台的截图:
我正在运行Javascript SDK v4.50和AngularFire2 v5.0 rc.2。
有人遇到过这个问题吗？
更新：2018年2月12日 - iOS Firestore SDK v0.10.0
与其他评论者类似，我也注意到第一次获取请求的响应速度较慢（后续请求大约需要100毫秒）。对我来说并不像30秒那么糟糕，但是在我有良好的连接时可能需要2-3秒，这足以在应用程序启动时提供不良用户体验。
Firebase表示他们已经意识到这个“冷启动”问题，并且正在为其寻求长期解决方案-不幸的是没有时间表。我认为当我连接质量差时，可能需要很长时间（超过30秒）才能从缓存中读取获取请求，这是一个单独的问题。
在Firebase解决所有这些问题之前，我开始使用新的disableNetwork()和enableNetwork()方法（在Firestore v0.10.0中可用）手动控制Firebase的在线/离线状态。尽管我必须在我的代码中非常小心地使用它，因为有一个Firestore错误，可以在某些情况下导致崩溃。
更新：2017年11月15日 - iOS Firestore SDK v0.9.2
似乎已经修复了性能缓慢的问题。我重新运行了下面描述的测试，现在Firestore返回100个文档所需的时间似乎始终稳定在约100毫秒左右。
不确定这是最新SDK v0.9.2中的修复还是后端的修复（或两者都有），但我建议每个人都更新他们的Firebase pods。我的应用程序响应速度明显更快-类似于Realtime DB。
我还发现Firestore比Realtime DB慢得多，特别是在读取大量文档时。
使用最新的iOS Firestore SDK v0.9.0进行更新测试：
我使用iOS Swift在RTDB和Firestore中设置了一个测试项目，并在每个数据库上运行了100个连续读取操作。对于RTDB，我测试了每个100个顶级节点上的observeSingleEvent和observe方法。对于Firestore，我在TestCol集合的每个100个文档中使用了getDocument和addSnapshotListener方法。我打开和关闭了磁盘持久性选项，并请参考附图，该图显示了每个数据库的数据结构。
我在同一设备和稳定的wifi网络上为每个数据库运行了10次测试。在每次新运行之前，销毁现有的观察者和监听器。
Realtime 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)")
}
}
}
实时数据库观察方法：
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中的问题所在？更新日期：2018年3月2日
看起来这是一个已知的问题，Firestore的工程师正在努力修复。在与Firestore的一位工程师进行了几次电子邮件交流和代码共享后，他对此问题的回复如下。
“你说得很正确。经过进一步检查，getDocuments（）API的缓慢性是Cloud Firestore beta中已知的行为。我们的工程师已经意识到这个被标记为“冷启动”的性能问题，但请放心，我们正在尽最大努力改进Firestore查询性能。
我们已经在着手长期解决方案，但目前我不能分享任何时间表或具体细节。虽然Firestore仍处于beta版本，但预计还会有更多的改进出现。”
所以希望这个问题很快就会被解决。
使用Swift / iOS
经过约3天的处理，似乎问题确实出在get()，即.getDocuments和.getDocument。我原本以为这些问题导致极端而间歇性的延迟，但事实并非如此：
我排除了所有这些可能性，因为我注意到这个问题并不是在我进行的每一个Firestore数据库调用中都发生。只有使用get()检索时才会出现。出于好奇，我将.getDocument替换为.addSnapshotListener来检索我的数据，结果惊人，每次都能立即检索，包括第一次调用。没有冷启动。到目前为止，.addSnapshotListener没有出现任何问题，只有getDocument(s)。
现在，当时间紧迫时，我只是放弃使用.getDocument()并将其替换为.addSnapshotListener，然后使用
for document in querySnapshot!.documents{
// do some magical unicorn stuff here with my document.data()
}
...以便在Firestore解决此问题之前继续移动。
近三年过去了，Firestore已经不再是测试版，但我可以证实这个可怕的问题仍然存在。在我们的移动应用程序中，我们使用JavaScript/Node.js Firebase客户端。经过多次测试，我们发现启动时间约为10秒，其中70%的时间都归因于Firebase和Firestore的性能和冷启动问题：
因此，用户初始化总共需要6-7秒，完全无法接受。而且我们无法解决它。我们不能测试禁用持久性，因为在JavaScript客户端中没有这样的选项，持久性默认始终启用，因此不调用enablePersistence()不会改变任何事情。
对于 Web，离线持久性默认处于禁用状态。要启用持久性，请调用 enablePersistence 方法 但是我可以确认，如果将其关闭，我们的初始请求时间从大约 8 秒降至约 500 毫秒左右。https://firebase.google.com/docs/firestore/manage-data/enable-offline - pat
现在返回100个项目（禁用离线持久性），我的查询只需要不到1秒钟就能完成。
我的Firestore查询代码如下：
let db = Firestore.firestore()
self.date = Date()
let ref = db.collection("collection").whereField("Int", isEqualTo: SomeInt).order(by: "AnotherInt", descending: true).limit(to: 100)
ref.getDocuments() { (querySnapshot, err) in
if let err = err {
print("Error getting documents: \(err)")
} else {
for document in querySnapshot!.documents {
let data = document.data()
//Do things
}
print("QUERY DONE")
let currentTime = Date()
let components = Calendar.current.dateComponents([.second], from: self.date, to: currentTime)
let seconds = components.second!
print("Elapsed time for Firestore query -> \(seconds)s")
// Benchmark result
}
}
目前我正在使用模拟器和真实的Android手机华为P8，进行研究工作。
Firestore和Cloud Storage都让我头疼，因为当我进行第一次document.get()和第一次storage.getDownloadUrl()时，响应速度非常慢。
每个请求都需要超过60秒的响应时间。这种缓慢的响应只会在真实的Android手机上出现，而不会在模拟器中出现。还有另外一件奇怪的事情，第一次遇到之后，其余的请求都很顺畅。
以下是我遇到缓慢响应的简单代码。
var dbuserref = dbFireStore.collection('user').where('email','==',email);
const querySnapshot = await dbuserref.get();
var url = await defaultStorage.ref(document.data().image_path).getDownloadURL();