FIX new blog post (JNI performance) Locate images correctly (#12050)

Summary:
We set up the images / references to the images wrongly in https://github.com/facebook/rocksdb/pull/11818
Images should be in the docs/static/images/… directory with an absolute reference to /static/images/…

Make it so.

Pull Request resolved: https://github.com/facebook/rocksdb/pull/12050

Reviewed By: pdillinger

Differential Revision: D51079811

Pulled By: jaykorean

fbshipit-source-id: 4c1ab80d313b70d0e60eec94086451d7b2814922

docs/_posts/2023-11-06-java-jni-benchmarks.markdown

@@ -106,7 +106,7 @@ Benchmarks ran for a duration of order 6 hours on an otherwise unloaded VM,
   the error bars are small and we can have strong confidence in the values
   derived and plotted.
 
-![Raw JNI Get](./jni-get-benchmarks/fig_1024_1_none_nopoolbig.png).
+![Raw JNI Get small](/static/images/jni-get-benchmarks/fig_1024_1_none_nopoolbig.png)
 
 Comparing all the benchmarks as the data size tends large, the conclusions we
 can draw are:
@@ -130,7 +130,7 @@ can draw are:
 
 At small(er) data sizes, we can see whether other factors are important.
 
-![Raw JNI Get](./jni-get-benchmarks/fig_1024_1_none_nopoolsmall.png)
+![Raw JNI Get large](/static/images/jni-get-benchmarks/fig_1024_1_none_nopoolsmall.png)
 
 - Indirect byte buffers are the most significant overhead here. Again, we can
   conclude that this is due to pure overhead compared to `byte[]` operations.
@@ -156,7 +156,7 @@ of result.
   the access is presumably word by word, using normal
   Java mechanisms.
 
-![Copy out JNI Get](./jni-get-benchmarks/fig_1024_1_copyout_nopoolbig.png).
+![Copy out JNI Get](/static/images/jni-get-benchmarks/fig_1024_1_copyout_nopoolbig.png)
 
 ### PutJNIBenchmark
 
@@ -227,7 +227,7 @@ java -jar target/rocksdbjni-jmh-1.0-SNAPSHOT-benchmarks.jar -p keyCount=1000,500
 ```
 The y-axis shows `ops/sec` in throughput, so higher is better.
 
-![image](./jni-get-benchmarks/optimization-graph.png)
+![](/static/images/jni-get-benchmarks/optimization-graph.png)
 
 ### Analysis
 
@@ -285,7 +285,3 @@ Luckily this is easy to fix. In the Java API (JNI) implementation:
 In the case where the `PinnableSlice` has succesfully pinned the data, this saves us the intermediate copy to the `std::string`. In the case where it hasn't, we still have the extra copy so the observed performance improvement depends on when the data can be pinned. Luckily, our benchmarking suggests that the pin is happening in a significant number of cases.
 
 On discussion with the RocksDB core team we understand that the core `PinnableSlice` optimization is most likely to succeed when pages are loaded from the block cache, rather than when they are in `memtable`. And it might be possible to successfully pin in the `memtable` as well, with some extra coding effort. This would likely improve the results for these benchmarks.
-
-
-
-