RSS feed [root] /design /weblog



title search:


Tue Jan 17 23:09:08 HKT 2017


(google search) (amazon search)
download zip of files only

Sun Mar 19 10:25:58 HKT 2017 From /weblog/design


The Hidden Dividends of Microservices -

Best practices -[..]constructing-micro-service-system-part03

Compare using library / service -[..]cy-management-whether-library-or-service

(google search) (amazon search)

Thu Mar 09 23:13:09 HKT 2017 From /weblog/design


Someone saying that having private method is anti-pattern, here is the discussion -

Discussion of encapsulation -[..]/encapsulation-does-it-really-exist.html

My view on this is that most of the time there's little value in self-encapsulation. The value of encapsulation is proportional to the scope of the data access. Classes are usually small (at least mine are) so direct access isn't going to be an issue within that scope. Most accessors are simple assignments for the setter and retrieval for the getter, so there's little value in using them internally. -

(google search) (amazon search)

Thu Feb 23 16:14:03 HKT 2017 From /weblog/design/interview


Interview with JOOQ founder -

(google search) (amazon search)

Tue Feb 21 17:44:20 HKT 2017 From /weblog/design


A paper show the evolution of a DSL -

A stock trading order example of DSL -[..]05/designing-internal-dsls-in-scala.html

What is the difference between API / DSL if we don't write a parser for our language? From Martin Fowler's blog - , it is mentioned:
Piers Cawley makes the point that a key characteristic of DSLs is their narrow focus on a domain.
I think this is a very good summary, usually if most of the APIs are getXXX() , setXXX(), loadXXX() , createXXX() ........ Then we mostly design APIs that expose low level detail to the API user to work on, which, is work but user probably work nicer if we can come up with language like API that allow users to do their work in more descriptive level.

I think if API design like that usually it will reduce the code duplication, what ever real duplication or conceptual duplication. It probably already apply "Tell, don't ask" style -

A discussion about applying "Tell, don't ask" which lead to message passing architecture -[..]07/10/do_messages_want_to_be_asynchr.php

And other discussion about "Tell, don't ask"[..]/2008/11/demeters-law-tell-dont-ask.html[..]part-two-demeters-law-tell-dont-ask.html[..]rt-three-demeters-law-tell-dont-ask.html

One good sample with explaination -[..]-it-really-domain-specific-language.html

Few links -

From CRUD to DDD -[..]2/15/from-crud-to-domain-driven-fluency/

I like this: "XML abuse reduction (conducting an “XML Intervention”)" -[..]ps-internal-dsl-draft-outline-notes.aspx

DSL maybe the result of encapsulation -

Excellent implementation of extending java yourself -

How DSL method named -[..]he-java-fluent-api-designer-crash-course

(google search) (amazon search)

Thu Feb 16 00:03:22 HKT 2017 From /weblog/design/pattern


(google search) (amazon search)

Tue Feb 07 15:44:58 HKT 2017 From /weblog/design


Nothing specific, mostly code clean up, refactoring and simplification, the performance boost was a surprise. <- This is a good one -[..]12/07/disruptor-v3-faster-hopefully.html

Is there anything we can do about this when designing algorithms and data-structures? Yes there is a lot we can do. If we perform chunks of work on data that is co-located, and we stride around memory in a predictable fashion, then our algorithms can be many times faster. For example rather than using bucket and chain hash tables, like in the JDK, we can employ hash tables using open-addressing with linear-probing. Rather than using linked-lists or trees with single items in each node, we can store an array of many items in each node. -[..]emory-access-patterns-are-important.html

Skip lists are used instead of b-trees because b-trees don’t scale. -[..]ast-mvcc-inmem-lockfree-codegen-and.html

Beware about the performance issue of static initalization -[..]-cause-problems-with-multi-threading-how

Experiment show why arraylist is better in most cases -

How to design low latency application in java -[..]5/chronicle-and-low-latency-in-java.html[..]ciples-of-high-performance-programs.html[..]principles-of-high-performance-programs/

Suggestion about how to determine number of thread pool -[..]rmine-Web-Applications-Thread-Poll-Size/

Beware the performance penalty of logging -

Keep thing dynamic -[..]ciples-of-high-performance-programs.html[..]st-rule-of-performance-optimisation.html[..]u/~rcs/research/interactive_latency.html[..]aling-data-platforms.html?SSLoginOk=true

Discuss about developing low latency financial application -

Discussion of object pooling -[..]-but-forgotten-trick-object-pooling.html[..]m_performance_part_1_object_pooling.html

Efficiency - the amount of work you need to do.
Performance - how fast you can do that work
Efficiency - governed by your algorithm
Performance - governed by your data structures.[..]e-difference-between-efficiency-and.html

Turning off power save mode on the CPU reduced brought the max latency from 11 msec down to 8 msec.
Guaranteeing threads will always have CPU resources using CPU isolation and thread affinity brought the maximum latency down to 14 microseconds.[..]eduler-jitter-using-cpu-isolation-a.html[..]

About design for performance for webapi -[..]y-decision-as-a-service-design-patterns/

check list -[..]ery-software-development-team-should-ask

Beware if system utilization over 80% -[..]/20/service-latency-and-utilisation.html

scalable-io-events-vs-multithreading-based -[..]lable-io-events-vs-multithreading-based/

How to find out bottleneck -[..]entile-latencies-in-Chronicle-Queue.html

(google search) (amazon search)

Mon Jan 23 18:33:07 HKT 2017 From /weblog/design/concurrency


Stealing thread -

Intel Guide for Developing Multithreaded Applications -[..]or-developing-multithreaded-applications

Difference ways to stop a thread -[..]ept_url=/hpc-high-performance-computing/

Interesting, I am not sure if I agree, but chrome ( which use fork ) are really cool in performance:
There’s another problem with Unix programming in Ruby that I’ll just touch on briefly: Java people and Windows people. They’re going to tell you that fork(2) is bad because they don’t have it on their platform, or it sucks on their platform, or whatever, but it’s cool, you know, because they have native threads, and threads are like, way better anyways.

Fuck that.

Don’t ever let anyone tell you that fork(2) is bad. Thirty years from now, there will still be a fork(2) and a pipe(2) and a exec(2) and smart people will still be using them to solve hard problems reliably and predictably, just like they were thirty years ago.

MRI Ruby people need to accept, like Python (you have seen multiprocessing, yes?), that Unix processes are one of two techniques for achieving reliable concurrency and parallelism in server applications. Threads are out. You can use processes, or async/events, or both processes and async/events, but definitely not threads. Threads are out.

1x1 win M*N -

Best number of threads:
N = number of CPUs
U = target CPU utilization (0 <= U <= 1)
W/C = ration of wait time to cpu time (measured through profiling)

threads = N * U * (1 + W/C) -[..]ratio-of-java-threads-to-cpus-on-solaris

Another post about tuning thread pool -[..]ortance-of-tuning-your-thread-pools.html

Threads Basics -

The Dos and Don'ts of Multithreading -[..]-26-09-low-level-threading-table-of.html

(google search) (amazon search)

Tue Jan 17 23:09:08 HKT 2017 From /weblog/design


(google search) (amazon search)

Tue Jan 17 22:58:18 HKT 2017 From /weblog/design


5 Hints You're Using A Map When You Should Be Using a Cache? -[..]ints-your-using-map-when-you-should.html

How hibernate design the cache -

Consider to do more careful update, not just update DB and dirty cache, but update DB and cache in a same time -

Caching can be architectural smell, some hint and some alternative -[..]2/is_caching_an_architectural_smell.html

General caching discussion -[..]are-architecture/caching-techniques.html[..]10-program-busting-caching-mistakes.html[..]B/web-cache/cachingmistakes.aspx?azid=74

(google search) (amazon search)

Wed Dec 07 18:48:22 HKT 2016 From /weblog/design

work with legacy

Simple ways to improve legacy code -

One approach to work with legacy code, instead of phrase by phrase or part by part, identify and improve the domain part first -[..]-efforts-to-replace-legacy-systems-fail/[..]egacy-applications-tests-modularization/

Note of common point for refactoring with legacy application -[..]/2016/10/unintentionally-obfuscated.html

(google search) (amazon search)

Tue Nov 29 00:12:57 HKT 2016 From /weblog/design/interview


"They build their own infrastructure for performance, reliability, and cost control reasons. By building it themselves they never have to say Amazon went down because it was company X's fault. Their software may not be more reliable than others, but they can fix, debug, and deployment much quicker than when working with a 3rd party."

Shel Kaphan -

(google search) (amazon search)

Tue Nov 15 10:53:50 HKT 2016 From /weblog/design

value object

Discussion of DTO -

Discussion of value object -

(google search) (amazon search)

Tue Nov 15 10:49:25 HKT 2016 From /weblog/design/concurrency


How to write safer concurrency code -

reentrant and thread safe functions -[..]/31/reentrant-and-thread-safe-functions/

Libraries / toolkits for multicore process -[..]intableArticle.jhtml?articleID=212900103

Introduction -[..]QQSNDLRSKHSCJUNN2JVN?articleID=212903586[..]CQSNDLRSKHSCJUNN2JVN?articleID=213001517

Collections of links -[..]rallel-Or-Get-Left-Behind.html&Itemid=29

Briefing of difference modeling of threading system -[..]intableArticle.jhtml?articleID=215900465[..]inners-guide-to-multithreaded-libraries/[..]haloms_blog/2010/08/concurrency-101.html

Saving the Failwhale: The Art of Concurrency (Page last updated December 2012, Added 2012-12-26, Author Dhanji R. Prasanna, Publisher informit). Tips:

1) Contention is unavoidable - some resources are just slower, and you must wait for them. The secrets to good concurrency are 1) ensuring that these slower resources are rarely used, and 2) during such waiting periods, giving the faster tiers other work to do so that they continue to be utilized well.
2) Overuse of synchronization constructs such as locks and mutexes leads to systems that perform poorly under load.
3) ConcurrentHashMap is an efficient thread-safe map while HashMap is not thread-safe.
4) ConcurrentHashMap doesn't do away with locks, it still uses them but it uses more than the single global lock, so that threads gain some measure of concurrency. It uses separate locks for partitions, so that multiple threads writing to the map are likely to access different partitions, using separate locks and therefore process their data simultaneously. This technique is known as lock-striping. Efficient striping uses a number of locks proportional to the number of CPU cores in a system.
5) The asynchronous processing model smooths resource spikes by adding requests to a queue which is serviced by a pool of workers - spikes in requests make the queue grow rather than overloading the workers. (The ExecutorService is essentially a thread pool accompanied by a task queue.)

Discussion of using difference model for concurrency -[..]cks-application-architecture-pros-a.html

Concurrency vs Parallelism -[..]/2013/12/concurrency-vs-parallelism.html

Compare between Actors, CSP, Disruptor and raw Threads -[..]omparision-of-different-concurrency.html

Few coding tips that should be useful for most languages -[..]erformance-scalability-and-liveness.html[..]2015/09/java-concurrency-essentials.html

Service Design
Do one thing, do it well
No shared operational state
Bound your queues
Name custom thread pools and register an UncaughtExceptionHandler
Prefer immutable data objects over mutable state[..]-to-25-billion-notifications-during.html

(google search) (amazon search)

Wed Nov 02 16:14:20 HKT 2016 From /weblog/design/pattern


understanding-retry-pattern-with-exponential-back-off-and-circuit-breaker-pattern -[..]al-back-off-and-circuit-breaker-pattern/

(google search) (amazon search)

Wed Nov 02 16:13:31 HKT 2016 From /weblog/design/concurrency


10-ways-to-reduce-lock-contention-in-threaded-programs -[..]ce-lock-contention-in-threaded-programs/

Discussion about lock the form and prevent 2 user edit it in the same time and currupt the object, what is the possible drawback. -[..]-optimistic-locking-isnt-a-silver-bullet

futexes -[..]ds/browse_thread/thread/3c3608a779dc6731

Spinning -[..]ome/lock-free-algorithms/tricks/spinning

Locks for rarely changed data, sound like good suggestion -[..]pic/comp.programming.threads/dyrbRKsj4gw

Try to use non-blocking approach if possible -[..]1/locks-condition-variables-latency.html

Concurrency without lock, and even without correctness? -

Single write principle -[..].au/2011/09/single-writer-principle.html

Comparing difference kind of locks again -[..]11/stampedlocktryoptimisticread-and.html

10-ways-to-reduce-lock-contention-in-threaded-programs -[..]ce-lock-contention-in-threaded-programs/

(google search) (amazon search)

Sun Oct 30 17:28:32 HKT 2016 From /weblog/design


Tired with duplicating Try-Catch for resource acquisition? Can try to create proxy method -[..]clarative-synchronization-with-java.html

Discussion of naming of if block -

Factors for choosing a strategic technology stack, runtime performance is not a factor for him, probably good idea -[..]1/04/factors-for-choosing-strategic.html

Don't think , stay focus -

Using class name as variable name is a bad thing? I doubt about it, but interesting idea -

The problem of using generic name -

Beware of where memory allocated, sometime there is no off side for lazy initalization -[..]ou-dare-to-change-hashmap-implementation

Some suggestion of how to code in order to prevent unreproducible bugs -[..]4/02/minimizing-unreproducible-bugs.html

More careful to check null -[..]et-paranoid-java-programming-techniques/

The fewer conditions you test for, the better your code “tastes”. -[..]ding-requirement-99749f37684a#.1glkhe7np

(google search) (amazon search)

Sun Oct 16 01:52:15 HKT 2016 From /weblog/design/interview


How yahoo use Hadoop for machine learning -

(google search) (amazon search)

Tue Oct 04 11:38:59 HKT 2016 From /weblog/design


A nice thread of discussing how to comment in code -

A Taxonomy Of Comments -[..]hniques/documentation/taxonomy-comments/

Everything have 2 sides -[..]s/documentation/comments-costs-benefits/

Example of comment haven't update freq enough -[..]even-good-code-comments-deteriorate.html

(google search) (amazon search)

Tue Sep 13 00:10:46 HKT 2016 From /weblog/design


*Do not use locks in the main transaction flow because they cause context switches, and therefore latency and unpredictable jitter.
*Never have more threads that need to run than you have cores available.
*Set affinity of threads to cores, or at least sockets, to avoid cache pollution by avoiding migration. This is particularly important when on a server class machine having multiple sockets because of the NUMA effect.
*Ensure uncontested access to any resource respecting the Single Writer Principle so that the likes of biased locking can be your friend.
*Keep call stacks reasonably small. Still more work to do here. If you are crazy enough to use Spring, then check out your call stacks to see what I mean! The garbage collector has to walk them finding reachable objects.
*Do not use finalizers.
*Keep garbage generation to modest levels. This applies to most JVMs but is likely not an issue for Zing.
*Ensure no disk IO on the main flow.
*Do a proper warm-up before beginning to measure.
*Do all the appropriate OS tunings for low-latency systems that are way beyond this blog. For example turn off C-States power management in the BIOS and watch out for RHEL 6 as it turns it back on without telling you!
*Macro-benchmarking is much more valuable than micro-benchmarking.
*Amazing results are achieved by truly agile companies, staffed by talented individuals, who are empowered to make things happen. Make sh*t happen is more important than following a process.[..]ughput-by-32x-and-reduce-latency-by.html[..]rything-you-know-about-latency-is-wrong/

How to monitor -[..]siness-value-from-performance-monitoring

How to measure latency -[..]/07/20/Latency-for-a-set-Throughput.html

Various cause of latency, and the solution -[..]Topics-in-High-Performance-Messaging.htm

(google search) (amazon search)

Fri Sep 09 16:00:46 HKT 2016 From /weblog/design/examples


How QQ deliver hotfix at Android -

(google search) (amazon search)

Wed Aug 17 00:06:59 HKT 2016 From /weblog/design/examples


How linkedin handle logs -[..]ould-know-about-real-time-datas-unifying

(google search) (amazon search)

Thu Jul 21 19:29:09 HKT 2016 From /weblog/design/distribute


There are two key primary ways of scaling web applications which is in practice today.
1) “Vertical Scalability” - Adding resource within the same logical unit to increase capacity. An example of this would be to add CPUs to an existing server, or expanding storage by adding hard drive on an existing RAID/SAN storage.
2) “Horizontal Scalability” - Adding multiple logical units of resources and making them work as a single unit. Most clustering solutions, distributed file systems, load-balancers help you with horizontal scalability.

Scalability can be further sub-classified based on the “scalability factor”.
1) If the scalability factor stays constant as you scale. This is called “linear scalability“.
2) But chances are that some components may not scale as well as others. A scalability factor below 1.0 is called “sub-linear scalability“.
3) Though rare, its possible to get better performance (scalability factor) just by adding more components (i/o across multiple disk spindles in a RAID gets better with more spindles). This is called “supra-linear scalability“.
4) If the application is not designed for scalability, its possible that things can actually get worse as it scales. This is called “negative scalability“.

Report of building web application with 55k pageload with rail -[..]mongrels-handled-a-550k-pageview-digging

XMPP a IM protocol about scalability -[..]icle/the_aol_xmpp_scalability_challenge/

Presentation and resources of making you website more scalable -[..]9/Real-World-Web-Performance-Scalability[..]lications&asrc=EM_NLN_3990118&uid=703565[..]ionsPart2&asrc=EM_NLN_3990119&uid=703565

Brian Zimmer, architect at travel startup Yapta, highlights some worst practices jeopardizing the growth and scalability of a system:
* The Golden Hammer. Forcing a particular technology to work in ways it was not intended is sometimes counter-productive. Using a database to store key-value pairs is one example. Another example is using threads to program for concurrency.
* Resource Abuse. Manage the availability of shared resources because when they fail, by definition, their failure is experienced pervasively rather than in isolation. For example, connection management to the database through a thread pool.
* Big Ball of Mud. Failure to manage dependencies inhibits agility and scalability.
* Everything or Something. In both code and application dependency management, the worst practice is not understanding the relationships and formulating a model to facilitate their management. Failure to enforce diligent control is a contributing scalability inhibiter.
* Forgetting to check the time. To properly scale a system it is imperative to manage the time alloted for requests to be handled.
* Hero Pattern. One popular solution to the operation issue is a Hero who can and often will manage the bulk of the operational needs. For a large system of many components this approach does not scale, yet it is one of the most frequently-deployed solutions.
* Not automating. A system too dependent on human intervention, frequently the result of having a Hero, is dangerously exposed to issues of reproducibility and hit-by-a-bus syndrome.
* Monitoring. Monitoring, like testing, is often one of the first items sacrificed when time is tight.

Useful Corporate Blogs that Talk About Scalability -[..]l-corporate-blogs-talk-about-scalability

Overview of mapreduce and how it compare with other distributed programming model -[..]0/is-mapreduce-going-to-main-stream.html

Paper of data store at amazon

Discuss how haven't sync can cause performance issue -[..]lications&asrc=EM_NLN_6273194&uid=703565

Discussion about Cloud Based Memory Architectures -[..]ased-memory-architectures-next-big-thing[..]alability-and-performance-best-practices

Interview with google engineer -[..]gle-at-scale-everything-breaks-40093061/

Surprisingly youtube is blocking -[..]e-scalability-lessons-in-30-minutes.html

If we are seeing a sustained arrival rate of requests, greater than our system is capable of processing, then something has to give. Having the entire system degrade is not the ideal service we want to give our customers. A better approach would be to process transactions at our systems maximum possible throughput rate, while maintaining a good response time, and rejecting requests above this arrival rate. -[..]apply-back-pressure-when-overloaded.html

How twitter scaling -

How Reddit scaling -

How Hotjar scaling -[..]-while-scaling-hotjars-tech-architecture

How infiniteDB prevent locking and IO -[..]-scalable-relational-database-manag.html[..]ard-way-about-scaling-a-million-use.html[..]2014/03/26/six-things-about-scaling.html

The experiences of various big companies, about network issues -

Stackoverflow, scale without cloud -[..]nth-25-servers-and-i.html?SSLoginOk=true

(google search) (amazon search)