如何对 MySQL、Postgresql、MongoDB 的速度进行基准测试/测试，这些地方有这么多缓存层？
我认为使用SQLite3，至少它不会保留任何缓存页面，因为没有服务器并且每次写入都会退出SQLite3，因此它无法直接进行任何缓存。
但是当它是 MySQL、Postgresql 或 MongoDB 时，会有一层，当数据被认为已经保存时，它实际上位于 DBMS 的内存缓存中......稍后会写入磁盘。
即使将其写入磁盘，也有一个操作系统层保留要写入磁盘的扇区。
然后是硬盘的缓存。由于它是 8MB，所以当测试插入数据创建 800MB 数据库时，错误可能会是 1% 或更少。
但是其他层呢？确实需要一直刷新到操作系统层。否则，对于具有 4GB RAM 或 8GB RAM 的计算机，当认为速度相当快时，整个数据库可以轻松驻留在 RAM 中。我们如何告诉测试将数据一直刷新到硬盘物理层或至少刷新到操作系统层？
I think with SQLite3, at least it doesn't keep any cached page because there is no server and each write will exit SQLite3, so it can't do any caching directly.
But when it is MySQL, Postgresql, or MongoDB, there will be a layer which, when the data is thought to be saved already, it is actually in the memory cache of the DBMS... to be written later to the disk.
And even when it is written to the disk, there is an OS layer that keeps sectors that are to be written to the disk.
And then there is the hard drive's cache. With it being 8MB, so maybe when the test is inserting data creating a 800MB database, then the error can be 1% or less.
But what about the other layers? There really needs to be flushing all the way to the OS layer. Otherwise, with computers having 4GB of RAM or 8GB of RAM, the whole database can easily reside in RAM when it is thought to be quite fast. How do we tell the test to flush the data all the way to the hard disk physical layer or at least out of the OS layer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当您进行基准测试时，您永远不能否定操作系统甚至 CPU 级别的每一层的所有速度优化，包括缓存。你不需要那个。您可以做的是对系统不同生命周期状态下的性能进行基准测试。另外，如果您知道（大约）缓存哪些数据，您可以在此之前和之后进行基准测试。例如 - 干净启动、首次数据库数据集访问、后续数据库访问等。最好首先建立瓶颈，然后仅在那里进行更详细的基准测试。另一个好的做法是模拟现实生活中的系统负载并对其进行基准测试。任何综合基准实际上都是毫无意义的。祝你好运 ;）
When you are doing benchmarking, you can never negate all the speed optimizations at every layer down to the OS or even CPU level, including caching. You don't need that. What you can do is to benchmark performance in the different lifecycle states of your system. Also, if you know what data is cached when (approximately) you can do benchmark before and after that. For example - clean start, first DB dataset access, subsequent DB access, etc. It is best to establish the bottlenecks first and then benchmark only there in greater details. Another good practise is to simulate a real life system load and benchmark that. Any syntetic benchmarks are practically pointless. Good luck ;)