3 ms·
My app server has had non-blocking IO on regular OS threads for 10 years. To hide things in "virtual threads" does not do you any favours in the long run becaus
by bullen 5y ago
My app server has had non-blocking IO on regular OS threads for 10 years. To hide things in "virtual threads" does not do you any favours in the long run because it just adds complexity; you need to understand things as close to the metal as possible to make it work as good as it can work: http://github.com/tinspin/rupy http://github.com/tinspin/rupy
To not use async. is really bad, you are wasting so much CPU. Even in a async. scenario just copying memory from user space to kernel and back takes 30% of the CPU at full 100% utilization, imagine having all those context switches too!
- bob1029 5y agoFurthermore, if all of the events being pushed into your application are needing to be processed in a serialized fashion anyways (i.e. any financial transaction system), then you will find that a single thread is the fastest way to process those items. The moment you involve a lock, you lose the instruction-level parallelism game. Threads are a huge mistake 9/10 times. I don't judge when the OS uses them, but for most of my applications I prefer to get everything into a nice ringbuffer so I can tear through tens or hundreds of millions of transactions per second with that single blessed core. Most of this is meaningless if you use a database engine to serialize your transactions for you, but its still worth considering from an abstract perspective IMO.