This content has been marked as final. Show 3 replies
Wow, that is interesting. But I would say JRTS would not fit in to this task. Just knowing 3-5 usec. is not much to say about the application. If you are careful 100 usec. is fine below 100 usec. difficult but possible. Below 10 usec. is possible no doubt about it. But alot of tuning required and careful programming, memory model, GC settings etc. and you are at the limits. good luck, can you share your experience later?
474KB in 5 microseconds? Thats 94.8 GB/second - > 758.4Gbps
Now double that as you need to read from disk then write to DB.
Now add some processing time for the parsing.
You need some awesome hardware processing power to achieve this!
Ignoring that lets consider the real-time issues:
a) you'll want to run in a NHRT at high priority (heap using threads will never be suitable unless you can guarantee they won't need to allocate, or won't ever run during GC)
b) you will have interrupt issues because you want to avoid any unnecessary interrupts, but you will need the I/O related interrupts of your own processing - and you don't have that level of control in Solaris
c) you'll need to ensure highest priority disk I/O with no priority inversions (no idea if that is even possible - you need to fully understand the disk I/O subsystem in Solaris
d) if your DB is accessed via network interface then (c) applies for networking too - and there are many perils in trying to do
You could take Java RTS right out of the picture and I doubt you can achieve this.
The latency goals of Java RTS on Solaris using NHRTs is in the tens of microseconds - and that's latency, not raw performance.
Thanks Hevren and David, the information was very helpful. Planned to reduce the data size.