mehrant

6 ms·

1.
Show HN: A screen recorder/editor that runs in browser(demoreel.app)
1 points by mehrant 5d ago|0 comments
2.
Show HN: Open-source, 3D mockup designer for apps(openmock.app)
5 points by mehrant 29d ago|0 comments
3.
Show HN: Building a full agentic harness around a 4B model is hard(orvena.app)
5 points by mehrant 29d ago|0 comments
4.
Show HN: Simulator for a custom 8-bit discreet logic computer(msap2.mehran.dk)
27 points by mehrant 2mo ago|5 comments
5.
by mehrant 1y ago
Feel free to test for yourself :) Test was done using Redis benchmark for 1M random keys, 50 clients, Pipeline depth, 64. I did this locally on my MBP M3-Max. This gives a little over 2M for Redis and 5.4M for Feox. redis-benchmark -n 10000
6.
by mehrant 1y ago
The Redis-compatible server is based on Feox DB, which is an embedded KV Store in Rust. https://github.com/mehrantsi/feoxdb
7.
Show HN: Drop-in Redis replacement in Rust with 5M+ GET/s(github.com)
25 points by mehrant 1y ago|3 comments
8.
Show HN: Feox Server, a Rust based, drop-in replacement for Redis(github.com)
2 points by mehrant 1y ago|0 comments
9.
by mehrant 1y ago
When operations complete in 200ns instead of blocking for microseconds/milliseconds on fsync, you avoid thread pool exhaustion and connection queueing. Each sync operation blocks that thread until disk confirms - tying up memory, conne
10.
by mehrant 1y ago
Thanks for the comment. :) The target use cases include: 1- Session stores (can be reconstructed from auth service) 2- leaderboards/counters (recent scores/counters can be recalculated) 3- Real-time analytics/metrics (losing
11.
by mehrant 1y ago
Thanks! yeah, SQLite's write lock is painful for concurrent apps. I'm comfortable with kernel development, so I brought some of those patterns here - RCU-style lock-free reads, per-CPU inspired sharded buffers, and io_uring for ke
12.
Show HN: FeOx – Fast embedded KV store in Rust(github.com)
37 points by mehrant 1y ago|8 comments
13.
by mehrant 1y ago
Reading your comment about comparing the throughput to Redis, it seems to me that you haven't read the benchmark article really. In there, we're in fact comparing the "throughput" and not the latency. allow me to quote s
14.
by mehrant 2y ago
One thing we'd like to know your opinion on, is our key monitoring via WebSocket (pub-sub) feature. You can read more about it in our documentation under WebSocket. Is it something that you think it's useful and you might have use
15.
by mehrant 2y ago
Thank you for your thoughtful critique. To clarify what our numbers actually mean and address your main question of "what does that number actually mean": 1- The 600ns figure represents precisely what you described - an in-memory
16.
by mehrant 2y ago
for the time being, have a look at this please: http://hpkv.io/videos/performance_local.webm this is 1M records, 3M operations on a single node, single thread, recorded in real time (1x). I understand that without acce
17.
by mehrant 2y ago
our p50 is indeed 600ns for write, the way I explained it. I understand that at this point, this can be read as "trust me bro" kind of statement, but I can offer you something. we can have a quick call and I provide you access to
18.
by mehrant 2y ago
thanks for the feedback :) our main target for "performance" value proposition are companies and businesses which will setup HPKV either locally (Enterprise plan) for nanosecond performance or in the cloud provider of their choosi
19.
by mehrant 2y ago
thank you :) it would be interesting to have a chat for sure. would you mind dropping an email on the email I mentioned in OP and I'll reach out to you.
20.
by mehrant 2y ago
your concern is understandable. we'll be in touch :)
21.
by mehrant 2y ago
We provide some elements of ACID guarantees, but not full ACID compliance as traditionally defined in database systems: Atomicity: Yes, for individual operations. Each key-value operation is atomic (it either completes fully or not at all).
22.
by mehrant 2y ago
of course. the speeds down to 15us can be achieved over network over our custom protocol on the same region. for sub-microsecond latency, you need to have HPKV running on the same machine as yours :)
23.
by mehrant 2y ago
sure! :)
24.
by mehrant 2y ago
yes, in that case data can potentially be lost. 30 sec in a worse case scenario without HA.
25.
by mehrant 2y ago
sorry for not being clear again. by saying this number does not represent full fsync operation, I meant it doesn't include the SSD write time. this is the time to update KVs internal memory structure + adding to write buffers. this is
26.
by mehrant 2y ago
thanks for taking time and commenting :) we'd still be happy if you decided to use it and give us your thoughts. as I mentioned in one of the comments below, we're hoping to go open source in future :)
27.
by mehrant 2y ago
the 600ns figure represents our optimized write path and not a full fsync operation. we achieve it -among other things- through: 1- as mentioned, we are not using any traditional filesystem and we're bypassing several VFS layers. 2- fr
28.
by mehrant 2y ago
thank you :)
29.
by mehrant 2y ago
the test was done on a single node and a single thread. on multi thread and batch operations, HPKV was still faster on the same machine
30.
by mehrant 2y ago
that's a great question. the 600ns figure represents our optimized write path and not a full fsync operation. we achieve it -among other things- through: 1- as mentioned, we are not using any traditional filesystem and we're bypas

More ›