跳至主要内容

博文

目前显示的是 四月, 2018的博文

Syncer Performance Tuning

Syncer Performance Tuning Recently, I re-read some chapter of Programming Pearls about the performance tuning. For notes about detailed basic principles to optimize performance, you may like to refer to this post . In those chapters, author concludes some optimization levels to check when performance becomes a problem: Design level (System architecture): run in parallel, do in async way etc; Algorithm level: space and time tradeoff; better algorithm & ADT; Code tuning: loop unrolling; lock opt; System Software JVM level: garbage collector chosen; command line argument tuning; OS level: network config; IO tuning; Hardware Now, we will apply above checklist of optimization levels to a specific project – syncer (syncer is a tool to sync & manipulate data from Mysql/MongoDB to Elasticsearch/Mysql/Http Endpoint) – to put the knowledge into practice and get better ideas about performance tuning. Prepare Data & Env The architecture of syncer

Monitor: Spring Boot Actuator & Prometheus (2)

Monitor: Spring Boot Actuator & Prometheus (2) In the last blog of this topic, we have make a simple runnable example using Spring Boot 2.0 and Prometheus to do the monitoring of system state. But to make it accessible for old version Spring & Jersey, we need to do more works. Metric in Actuator In order to migrate the functionality to old versioned Spring & Jersey, we have to understand how actuator achieve it. The actuator provides a serials of endpoints (like headdump , logfile , metrics , env ) to monitor and get information from our applications and we focus only on metric related endpoints. The metric module has three main abstractions: Metric: the class hold the metric in form of key & value with timestamp; Counter: the service used to increment/decrease count for a metric, like visitor count; Gauge: the service used to set a value for a metric, like CPU usage, Memory usage; The auto configured default implementation is relative sim

Intention Behind ClassLoader Design

Intention Behind ClassLoader Design We are always talking about the parent delegation model in ClassLoader design (if you are not familiar with this phrase, you may like to refer here ), but we seldom ask why such a design? What the intention behind it? In this blog, we will elaborate on this aspect. Parent Delegation in Detail The ClassLoader is the abstraction that is responsible to load the core of Java world – class. We give a name of class to ClassLoader and it give us the class instance 1 . public Class < ? > loadClass ( String name ) throws ClassNotFoundException { } The delegation model of Java ClassLoader requires that any request for a class loader to load a given class should be first delegated to its parent class loader before do it by itself. if ( parent != null ) { c = parent . loadClass ( name , false ) ; } else { c = findBootstrapClassOrNull ( name ) ; } if ( c == null ) { // If still not fou