umesh9794 commented on PR #10549: URL: https://github.com/apache/ozone/pull/10549#issuecomment-4957119344
> @umesh9794 thanks for addressing some concerns in your latest commit, however below points are still open: > > 1. remove the dead code `replaceUnhealthyContainerRecordsAtomically` > 2. I still don't see the real performance comparison as per my comment in earlier review iteration.File based derby and memory based run performance figures are not the real comparison. Thanks, I removed the dead code. The earlier shared performance comparisons were between different runs with in-memory derby only and not the file based derby. Please refer below table : | Run | Code Version | DB | |--------|--------|--------| | 82s | [Cell](master: delete-all + re-insert) | in-memory Derby | | 18s | Diff based sync | in-memory Derby | | 17.5s | diff-based sync + JDBC batching | in-memory Derby | I can see production Recon uses file-based Derby, not in-memory. So these absolute numbers are optimistic ā real production timings would be higher because of disk I/O and fsync that this benchmark deliberately removes. Because it's in-memory (and even file-based Derby is local/embedded, not networked), the JDBC batching win is understated in these numbers. Batching mainly saves round-trips IMO; there are none to save in-memory. On file-based Derby, batching (fewer commits/statement executions against disk) could show a somewhat larger benefit than the ~18sā17.5s seen here ā but the dominant real-world win can be the change-detection skip of unchanged rows. What do you think? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
