I don't think we're cheating, as such. I think the messenger and the ObjectStore implementation will indeed dominate the overall cpu usage and latency for reads in the common case for both classic and crimson, so the setup we've got for crimson is probably reasonable. If we're actually worried about it, we could probably short-circuit the classic osd in the same way and get numbers that way? Actually adding the checks (by which I mean whatever is required for crimson to behave like an osd, not necessarily what's in classic) is pretty much implementing the full read and write paths for crimson, so I'd guess that's where we're going anyway? -Sam On Wed, Apr 3, 2019 at 5:35 AM kefu chai <tchaikov@xxxxxxxxx> wrote: > > in today's standup meeting, we were discussing the apple-to-apple > comparison. i think it still matters to have a rough apple-to-apple > comparison to make sure we don't cut corners and hence won't be > over-optimistic when benchmarking crimson-osd. > > if we are "cheating" and just connecting the messenger and backend > store, skipping the critical factors that have significant impacts on > the performance in classic OSD in normal i/o patterns. our test result > won't be representative. > > i think one of the reasons why we implemented the read path first is > that it is a typical i/o operation that we can have with minimal > efforts. if the various checks are playing a significant role slowing > down OSD, then we should at least understand if they still apply in > crimson-osd. if yes, we should implement them, i guess. checksum > verification based on object-info might be one of them. probably we > can indeed skip this step, assuming bluestore will be dominant very > soon. > > > -- > Regards > Kefu Chai
