diff --git a/README.md b/README.md
index ca33b16..74268a0 100644
--- a/README.md
+++ b/README.md
@@ -790,13 +790,17 @@ batchsize=1000下，线程数对性能的影响：
 
 这一实验体现了leveldb写队列策略在不同情况下的优劣。而我们fielddb的请求队列策略和这个基本一致，性能使用场景具有相似性。  
 
-2. 对于FieldDB的分析
+2. 对于FieldDB的分析  
 单线程  
 ![alt text](pics/field单.png)  
 双线程  
 ![alt text](pics/field双.png)
 1） 所有涉及读取性能的：和原版leveldb相比，损耗非常少（一个必要的字段解析步骤），还是非常好的  
 2） 常规的写入性能：有所下降，但是由于需要支持索引功能，一些额外的开销无法避免（例如先读一遍，并发控制，一致性维护）。fillbatch的测试，基于我们合并请求和一段请求只处理一次同名key的算法，多线程性能甚至比单线程能够提高许多    
+![alt text](pics/f_bsize.png)  
+![alt text](pics/f_thread.png)   
+其中单线程fillbatch差异比较明显。这里面的主要原因，一是因为leveldb本身这方面性能就非常优秀，二是因为在有索引功能的情况下，为了避免之前提到的问题，我们处理batch实际上还是需要把里面的每一条数据拆分出来，分别创建请求处理（而不是直接批量写入）。  
+这也反映在batchsize图中，我们的性能上升速率不如leveldb。但同样可观的上升速率意味着，我们的请求处理算法是有一定效果的。  
 3） 对于创删索引：没有比较对象，但是总体可以接受  
 4） 对于创删索引和写并发：如果是无关的，那么还是保持了高吞吐；如果是相关的，那么不得不受限于创删索引。考虑到数据库的创删索引请求还是比较少的（不太可能出现我们测试中，不停并发创删索引和写入的情况），一定的性能牺牲可以接受
 
diff --git a/pics/f_bsize.png b/pics/f_bsize.png
new file mode 100644
index 0000000..b1e1a4c
Binary files /dev/null and b/pics/f_bsize.png differ
diff --git a/pics/f_thread.png b/pics/f_thread.png
new file mode 100644
index 0000000..195f509
Binary files /dev/null and b/pics/f_thread.png differ