3 minor spelling correction
source | link

There are a bunch of things to be aware of yes. I'm in Crete at the moment with limited net access so this will be (fairly) short. Also, I'm not a low-latency expert, but several of my colleagues play one in real life :-).

  1. You need to appreciate Mechanical Sympathy (a term coined by Martin Thompson). In other words you need to understand what your underlying hardware is doing. Knowing how CPUs load cache lines, what their read/write bandwithbandwidth is, speed of main memory and much, much more is very important. Why? Because you'll need to reason how your Java source code affects the OperatingSystem/Hardware via the runtime JVM. For example, is the way your field variables are laid out in your source code causing cache line evictions (costs you ~150 clock cycles), hmmm... :-).

  2. GenrallyGenerally you want lock free algorithms and I/O. Even the most well designed concurrent application (that uses locks) is at risk of blocking, blocking in low latency is generally bad :-).

  3. Understand Object Allocation and Garbage Collection. This is a massive topic, but basically you want to avoid GC pauses (often caused by the Stop the World nature of various GC collections). Specialist GC collectors like the Azul collector can in many cases solve this problem for you out of the box, but for most people they need to understand how to tune the Sun/Oracle GCs (CMS, G1, etc).

  4. The Hotspot JIT is freaking amazing. Learn about its optimzationsoptimizations, but generally speaking all of the good OO techniques (encapsulation, small methods, as much immutable data as possible) will allow JIT to optimize, giving you the sorts of performance levels that well crafted C/C++ code gives you.

  5. Overall system architecture. Be aware of the network, how machines are co-located, if you're connected to the exchange via fiber etc etc.

  6. Be aware of the impact of logging. logging binary or using coded output that you can parse off line is probably a good idea.

Overall I highly recommend going on Kirk Pepperdine's Java Performance Tuning course [Disclaimer: I teach this course myself, so I'm biased]. You'll get good coverage of the various aspects of the JVM and its impact on underlying O/S and hardware.

PS: I'll try to revisit this later and tidy it up some.

There are a bunch of things to be aware of yes. I'm in Crete at the moment with limited net access so this will be (fairly) short. Also, I'm not a low-latency expert, but several of my colleagues play one in real life :-).

  1. You need to appreciate Mechanical Sympathy (a term coined by Martin Thompson). In other words you need to understand what your underlying hardware is doing. Knowing how CPUs load cache lines, what their read/write bandwith is, speed of main memory and much, much more is very important. Why? Because you'll need to reason how your Java source code affects the OperatingSystem/Hardware via the runtime JVM. For example, is the way your field variables are laid out in your source code causing cache line evictions (costs you ~150 clock cycles), hmmm... :-).

  2. Genrally you want lock free algorithms and I/O. Even the most well designed concurrent application (that uses locks) is at risk of blocking, blocking in low latency is generally bad :-).

  3. Understand Object Allocation and Garbage Collection. This is a massive topic, but basically you want to avoid GC pauses (often caused by the Stop the World nature of various GC collections). Specialist GC collectors like the Azul collector can in many cases solve this problem for you out of the box, but for most people they need to understand how to tune the Sun/Oracle GCs (CMS, G1, etc).

  4. The Hotspot JIT is freaking amazing. Learn about its optimzations, but generally speaking all of the good OO techniques (encapsulation, small methods, as much immutable data as possible) will allow JIT to optimize, giving you the sorts of performance levels that well crafted C/C++ code gives you.

  5. Overall system architecture. Be aware of the network, how machines are co-located, if you're connected to the exchange via fiber etc etc.

  6. Be aware of the impact of logging. logging binary or using coded output that you can parse off line is probably a good idea.

Overall I highly recommend going on Kirk Pepperdine's Java Performance Tuning course [Disclaimer: I teach this course myself, so I'm biased]. You'll get good coverage of the various aspects of the JVM and its impact on underlying O/S and hardware.

PS: I'll try to revisit this later and tidy it up some.

There are a bunch of things to be aware of yes. I'm in Crete at the moment with limited net access so this will be (fairly) short. Also, I'm not a low-latency expert, but several of my colleagues play one in real life :-).

  1. You need to appreciate Mechanical Sympathy (a term coined by Martin Thompson). In other words you need to understand what your underlying hardware is doing. Knowing how CPUs load cache lines, what their read/write bandwidth is, speed of main memory and much, much more is very important. Why? Because you'll need to reason how your Java source code affects the OperatingSystem/Hardware via the runtime JVM. For example, is the way your field variables are laid out in your source code causing cache line evictions (costs you ~150 clock cycles), hmmm... :-).

  2. Generally you want lock free algorithms and I/O. Even the most well designed concurrent application (that uses locks) is at risk of blocking, blocking in low latency is generally bad :-).

  3. Understand Object Allocation and Garbage Collection. This is a massive topic, but basically you want to avoid GC pauses (often caused by the Stop the World nature of various GC collections). Specialist GC collectors like the Azul collector can in many cases solve this problem for you out of the box, but for most people they need to understand how to tune the Sun/Oracle GCs (CMS, G1, etc).

  4. The Hotspot JIT is freaking amazing. Learn about its optimizations, but generally speaking all of the good OO techniques (encapsulation, small methods, as much immutable data as possible) will allow JIT to optimize, giving you the sorts of performance levels that well crafted C/C++ code gives you.

  5. Overall system architecture. Be aware of the network, how machines are co-located, if you're connected to the exchange via fiber etc etc.

  6. Be aware of the impact of logging. logging binary or using coded output that you can parse off line is probably a good idea.

Overall I highly recommend going on Kirk Pepperdine's Java Performance Tuning course [Disclaimer: I teach this course myself, so I'm biased]. You'll get good coverage of the various aspects of the JVM and its impact on underlying O/S and hardware.

PS: I'll try to revisit this later and tidy it up some.

2 added 279 characters in body
source | link

There are a bunch of things to be aware of yes. I'm in Crete at the moment with limited net access so this will be (fairly) short. Also, I'm not a low-latency expert, but several of my colleagues play one in real life :-).

  1. You need to appreciate Mechanical Sympathy (a term coined by Martin Thompson). In other words you need to understand what your underlying hardware is doing. Knowing how CPUs load cache lines, what their read/write bandwith is, speed of main memory and much, much more is very important. Why? Because you'll need to reason how your Java source code affects the OperatingSystem/Hardware via the runtime JVM. For example, is the way your field variables are laid out in your source code causing cache line evictions (costs you ~150 clock cycles), hmmm... :-).

  2. Genrally you want lock free algorithms and I/O. Even the most well designed concurrent application (that uses locks) is at risk of blocking, blocking in low latency is generally bad :-).

  3. Understand Object Allocation and Garbage Collection. This is a massive topic, but basically you want to avoid GC pauses (often caused by the Stop the World nature of various GC collections). Specialist GC collectors like the Azul collector can in many cases solve this problem for you out of the box, but for most people they need to understand how to tune the Sun/Oracle GCs (CMS, G1, etc).

  4. The Hotspot JIT is freaking amazing. Learn about its optimzations, but generally speaking all of the good OO techniques (encapsulation, small methods, as much immutable data as possible) will allow JIT to optimize, giving you the sorts of performance levels that well crafted C/C++ code gives you.

  5. Overall system architecture. Be aware of the network, how machines are co-located, if you're connected to the exchange via fiber etc etc.

  6. Be aware of the impact of logging. logging binary or using coded output that you can parse off line is probably a good idea.

Overall I highly recommend going on Kirk Pepperdine's Java Performance Tuning course [Disclaimer: I teach this course myself, so I'm biased]. You'll get good coverage of the various aspects of the JVM and its impact on underlying O/S and hardware.

PS: I'll try to revisit this later and tidy it up some.

There are a bunch of things to be aware of yes. I'm in Crete at the moment with limited net access so this will be (fairly) short. Also, I'm not a low-latency expert, but several of my colleagues play one in real life :-).

  1. You need to appreciate Mechanical Sympathy (a term coined by Martin Thompson). In other words you need to understand what your underlying hardware is doing. Knowing how CPUs load cache lines, what their read/write bandwith is, speed of main memory and much, much more is very important. Why? Because you'll need to reason how your Java source code affects the OperatingSystem/Hardware via the runtime JVM. For example, is the way your field variables are laid out in your source code causing cache line evictions (costs you ~150 clock cycles), hmmm... :-).

  2. Genrally you want lock free algorithms and I/O. Even the most well designed concurrent application (that uses locks) is at risk of blocking, blocking in low latency is generally bad :-).

  3. Understand Object Allocation and Garbage Collection. This is a massive topic, but basically you want to avoid GC pauses (often caused by the Stop the World nature of various GC collections). Specialist GC collectors like the Azul collector can in many cases solve this problem for you out of the box, but for most people they need to understand how to tune the Sun/Oracle GCs (CMS, G1, etc).

  4. The Hotspot JIT is freaking amazing. Learn about its optimzations, but generally speaking all of the good OO techniques (encapsulation, small methods, as much immutable data as possible) will allow JIT to optimize, giving you the sorts of performance levels that well crafted C/C++ code gives you.

Overall I highly recommend going on Kirk Pepperdine's Java Performance Tuning course [Disclaimer: I teach this course myself, so I'm biased]. You'll get good coverage of the various aspects of the JVM and its impact on underlying O/S and hardware.

PS: I'll try to revisit this later and tidy it up some.

There are a bunch of things to be aware of yes. I'm in Crete at the moment with limited net access so this will be (fairly) short. Also, I'm not a low-latency expert, but several of my colleagues play one in real life :-).

  1. You need to appreciate Mechanical Sympathy (a term coined by Martin Thompson). In other words you need to understand what your underlying hardware is doing. Knowing how CPUs load cache lines, what their read/write bandwith is, speed of main memory and much, much more is very important. Why? Because you'll need to reason how your Java source code affects the OperatingSystem/Hardware via the runtime JVM. For example, is the way your field variables are laid out in your source code causing cache line evictions (costs you ~150 clock cycles), hmmm... :-).

  2. Genrally you want lock free algorithms and I/O. Even the most well designed concurrent application (that uses locks) is at risk of blocking, blocking in low latency is generally bad :-).

  3. Understand Object Allocation and Garbage Collection. This is a massive topic, but basically you want to avoid GC pauses (often caused by the Stop the World nature of various GC collections). Specialist GC collectors like the Azul collector can in many cases solve this problem for you out of the box, but for most people they need to understand how to tune the Sun/Oracle GCs (CMS, G1, etc).

  4. The Hotspot JIT is freaking amazing. Learn about its optimzations, but generally speaking all of the good OO techniques (encapsulation, small methods, as much immutable data as possible) will allow JIT to optimize, giving you the sorts of performance levels that well crafted C/C++ code gives you.

  5. Overall system architecture. Be aware of the network, how machines are co-located, if you're connected to the exchange via fiber etc etc.

  6. Be aware of the impact of logging. logging binary or using coded output that you can parse off line is probably a good idea.

Overall I highly recommend going on Kirk Pepperdine's Java Performance Tuning course [Disclaimer: I teach this course myself, so I'm biased]. You'll get good coverage of the various aspects of the JVM and its impact on underlying O/S and hardware.

PS: I'll try to revisit this later and tidy it up some.

1
source | link

There are a bunch of things to be aware of yes. I'm in Crete at the moment with limited net access so this will be (fairly) short. Also, I'm not a low-latency expert, but several of my colleagues play one in real life :-).

  1. You need to appreciate Mechanical Sympathy (a term coined by Martin Thompson). In other words you need to understand what your underlying hardware is doing. Knowing how CPUs load cache lines, what their read/write bandwith is, speed of main memory and much, much more is very important. Why? Because you'll need to reason how your Java source code affects the OperatingSystem/Hardware via the runtime JVM. For example, is the way your field variables are laid out in your source code causing cache line evictions (costs you ~150 clock cycles), hmmm... :-).

  2. Genrally you want lock free algorithms and I/O. Even the most well designed concurrent application (that uses locks) is at risk of blocking, blocking in low latency is generally bad :-).

  3. Understand Object Allocation and Garbage Collection. This is a massive topic, but basically you want to avoid GC pauses (often caused by the Stop the World nature of various GC collections). Specialist GC collectors like the Azul collector can in many cases solve this problem for you out of the box, but for most people they need to understand how to tune the Sun/Oracle GCs (CMS, G1, etc).

  4. The Hotspot JIT is freaking amazing. Learn about its optimzations, but generally speaking all of the good OO techniques (encapsulation, small methods, as much immutable data as possible) will allow JIT to optimize, giving you the sorts of performance levels that well crafted C/C++ code gives you.

Overall I highly recommend going on Kirk Pepperdine's Java Performance Tuning course [Disclaimer: I teach this course myself, so I'm biased]. You'll get good coverage of the various aspects of the JVM and its impact on underlying O/S and hardware.

PS: I'll try to revisit this later and tidy it up some.