Showing posts with label Book. Show all posts
Showing posts with label Book. Show all posts

26.12.11

Java Performance - Ideal CPU Utilization?


  • High kernel or system CPU utilization can be an indication of shared resource contention or a large number of interactions between I/O devices.
  • The ideal situation for maximum application performance and scalability is to have 0% kernel or system CPU utilization since CPU cycles spent executing in operating system kernel code are CPU cycles that could be utilized by application code.
  • Hence, one of the objectives to achieving maximum application performance and scalability is to reduce kernel or system CPU utilization as much as possible.
This is something I didn't know before.

Java Performance - Evaluating a System's Performance


  • A common approach used to qualify or evaluate the performance of a new system has been to place a portion of the expected target load on the system, or execute one or more micro-benchmarks and observe how the system performs or observe the amount of work the application does per some unit of time.
  • However, to evaluate the performance of a SPARC T-series processor, it must be loaded with enough concurrent application threads to keep the large number of hardware threads busy.
  • The workload needs to be large enough for the SPARC T-series to reap the benefit of switching to a different runnable thread on the next clock cycle when long latency event such as CPU cache misses occur.
It seems to me that the author tried to explain to us why SPARC T-series perform so bad, instead of telling us the right approach to test the system performance. He paid very little attention to other platforms or CPU architectures, but just tried to downplay the others. Maybe it is not true. But that is my feeling when I read this section.

Java Performance - Choosing the Right Platform and Evaluating a System


  • The application may be running on an inappropriate CPU architecture or system.
That's interesting. Java application is supposed to be crossing platform, which means it could fit itself into the different CPU architectures or operating systems. However, according to this, we need to tune something to let the application suit itself into the new environment.

  • Multiple cores per CPU

A multi-core processor is a single computing component with two or more independent actual processors (called "cores"), which are the units that read and execute program instructions.[1] The instructions are ordinary cpu instructionslike add, move data, and branch, but the multiple cores can run multiple instructions at the same time, increasing overall speed for programs amenable to parallel computing. Manufacturers typically integrate the cores onto a singleintegrated circuit die (known as a chip multiprocessor or CMP), or onto multiple dies in a single chip package.


  • Multiple threads per core (CMT, chip multithreading)
Using CMT as the keyword, I found something related but not sure whether it is the same in Wikipedia.


Although many people reported that Sun Microsystems' UltraSPARC T1 (known as "Niagara" until its 14 November 2005 release) and the now defunct processor codenamed "Rock" (originally announced in 2005, but after many delays cancelled in 2009) are implementations of SPARC focused almost entirely on exploiting SMT and CMP techniques, Niagara is not actually using SMT. Sun refers to these combined approaches as "CMT", and the overall concept as "Throughput Computing". The Niagara has 8 cores, but each core has only one pipeline, so actually it uses fine-grained multithreading. Unlike SMT, where instructions from multiple threads share the issue window each cycle, the processor uses a round robin policy to issue instructions from the next active thread each cycle. This makes it more similar to a barrel processor. Sun Microsystems' Rock processor is different, it has more complex cores that have more than one pipeline.



In processor design, there are two ways to increase on-chip parallelism with less resource requirements: one is superscalar technique which tries to increase instruction level parallelism (ILP), the other ismultithreading approach exploiting thread level parallelism (TLP).

Superscalar means executing multiple instructions at the same time while chip-level multithreading (CMT) executes instructions from multiple threads within one processor chip at the same time.

Interleaved multithreading: Interleaved issue of multiple instructions from different threads, also referred to as Temporal multithreading. It can be further divided into fine-grain multithreading or coarse-grain multithreading depending on the frequency of interleaved issues. Fine-grainmultithreading—such as in a barrel processor -- issues instructions for different threads after every cycle, while coarse-grain multithreading only switches to issue instructions from another thread when the current executing thread causes some long latency events (like page fault etc.). Coarse-grain multithreading is more common for less context switch between threads. For example, Intel's Montecitoprocessor uses coarse-grain multithreading, while Sun's UltraSPARC T1 uses fine-grain multithreading. For those processors that have only one pipeline per core, interleaved multithreading is the only possible way, because it can issue at most one instruction per cycle.


A CPU cache is a cache used by the central processing unit of a computer to reduce the average time to access memory. The cache is a smaller, faster memory which stores copies of the data from the most frequently used main memory locations. As long as most memory accesses are cached memory locations, the average latency of memory accesses will be closer to the cache latency than to the latency of main memory.  A cache miss refers to a failed attempt to read or write a piece of data in the cache, which results in a main memory access with much longer latency. There are three kinds of cache misses: instruction read miss, data read miss, and data write miss.

  • One of the major design points behind the SPARC T-series processors is to address CPU cache misses by introducing multiple hardware threads per core.
    • UltraSPARC T1 has four hardware threads per core and comes in four, six, or eight cores per CPU.
    • 8 x 4 = 32
    • An UltraSPACE T1 processor with eight cores looks like a 32-processor system from an operating system viewpoint.
    • That is, the operating system views each of the four hardware threads per core as a processor.
    • Of the four hardware threads per core, only one of the four threads per core executes on a given clock cycle - because there is only one pipeline per core.
    • However, when a long latency event occurs, such as a CPU cache miss, if there is another runnable hardware thread in the same UltraSPARC T1 core, that hardware thread executes on the next clock cycle.
      • Does it mean T1 won't switch the threads at all at those situation?
    • In contrast, other modern CPUs with a single hardware thread per core, or even hyperthreaded cores, will block on long latency events such as CPU cache misses and may waste clock cycles while waiting for a long latency event to be satisfied.
      • I don't understand this.
      • In other modern CPUs, if another runnable application thread is ready to run and no other hardward threads are available, a thread context switch must occur before another runnable application thread can execute.
      • So, compare to T1, there are always redundant hardware threads over there and the CPU just picks up one and continues running, right? So, redundant threads are waste by itself, right? I don't understand. 
      • Thread context switches generally take hundreds of clock cycles to complete. Hence, on a highly threaded application with many thread ready to execute, the SPACE T-series processors have the capability to execute the application faster as a result of their capability to switch to another runnable thread within a core on the next clock cycle. The capability to have multiple hardware threads per core and switch to a different runnable hardware hread in the same core on the next clock cycle comes at the expense of a CPU with a slower clock rate. In other words, CPUs such as the SPARC T-series processor that have multiple hardware threads tend to execute at a lower clock rate than other modern CPUs that have a single hardware thread per core or do not offer the capability to switch to another runnable hardware thread on a subsequent clock cycle.

23.12.11

ActiveMQ in Action–Chapter 1 - When

  • Not  only  will  a change to one component in the system not ripple across the entire system, but component  interaction  is  also  dramatically  simplified.

I truly doubt it. Smile It may be true for component interaction per se, but not for system architecture design.

Loosely coupling and asynchronous communication approach add a lot of complexity into architecture design. At least, it is very much against the traditional way of designing the system, so that system architects need to learn how to design the system using Message Queuing approach, instead of using direct communication approaches.

  • EDA
    • Instead  of  using  a  synchronous scheme for component interaction (where one method calls another and  the  caller  waits  for  a  response  from  the  callee),  components  utilize  asynchronous communications (where they simply send a message without waiting
      for a response—also known as  fire-and-forget ). Such loose coupling throughout a system can lead to what’s known as an  event-driven architecture  (EDA).
    • Event-driven architecture - Wikipedia, the free encyclopedia

First of all, system architects from old schools with a bunch of developers from ancient would probably design a system in a synchronous scheme for component interaction with Message Queuing support. That’s not EDA at all.

On the other hand, EDA is one of the essential architecture skills you must have before you can fully make use of Message Queuing.

  • The decoupled, asynchronous style of architecture described in the previous point allows the broker itself to scale much  further  and  handle  considerably  more  clients  via  tuning,  additional memory allocation, and so on (known as vertical scalability) instead of only relying upon the ability of the number of broker nodes to be increased to handle many more clients (known as horizontal scalability).

Scalability - Wikipedia, the free encyclopedia

  • Horizontal Scaling
    • Scale horizontally (scale out)
    • To scale horizontally (or scale out) means to add more nodes to a system, such as adding a new computer to a distributed software application.
    • Brokers are distributed software components/nodes. Adding a broker is a kind of scaling out or horizontal scaling.
  • Vertical Scaling
    • Scale vertically (scale up)
    • To scale vertically (or scale up) means to add resources to a single node in a system, typically involving the addition of CPUs or memory to a single computer.
    • Such vertical scaling of existing systems also enables them to use virtualization technology more effectively, as it provides more resources for the hosted set of operating system and application modules to share.
    • So adding memory is a kind of vertical scaling.
    • When doing system tuning by adding more memory or more CPUs or more CPU cores, we are doing vertical scaling.

ActiveMQ in Action - Part 1



  • Not only is messaging a style of communication between applications, it’s also a style of integration
    • Notification
    • Inter-operation
I don't really understand this. But I guess the relationship is:
  • Communication <=> Notification
  • Integration <=> Inter-operation
Although it doesn't make much sense to me.


22.12.11

ActiveMQ in Action - About this book


  • Four parts
    • Part 1 provides an introduction to ActiveMQ, a high-level overview of JMS, and a brief discussion of the examples used throughout the book.
    • Part 2 focuses on the three standard components in ActiveMQ including connectivity into the message broker, message persistence, and message broker security.
    • Part 3 is using ActiveMQ to build application using technologies such as the Spring Framework, leading open source application servers, and numerous applications beyond just Java.
    • Part 4 discusses advanced features in ActiveMQ such as high availability, scalability, many advanced broker and client features, performance tuning, and administration of ActiveMQ.

  • Part 1
    • Chapter 1, Introduces ActiveMQ at a high level and discusses why and when to use ActiveMQ.
    • Chapter 2, Introduces enterprise messaging, message-oriented middleware (MOM) and the JMS specification.
    • Chapter 3, Introduces the examples to be used throughout ActiveMQ in Action.
  • Part 2
    • Chapter 4, Covers all the connectivity options for ActiveMQ.
      • URIs
      • The transport connectors
        • Client to broker
        • Broker to Broker
      • TCP
      • NIO
      • STOMIP
      • failover
      • SSL
      • HTTP/S
    • Chapter 5, Discusses message persistence in ActiveMQ
      • For Queue
      • For Topics
      • Four styles of message stores
      • Message caching
    • Chapter 6, Introduces and elaborates on security in ActiveMQ.
      • Authentication
      • Authorization
      • Certificate-based security
      • How to create a custom security plug-in
  • Part 3
    • Chapter 7, Deals with creating Java applications using ActiveMQ
    • Chapter 8, Is all about integrating ActiveMQ with some popular open source application servers.
      • Tomcat
      • Jetty
      • Geronimo
      • JBoss
      • client-side JNDI support
    • Chapter 9, Discusses messaging with ActiveMQ using languages other than Java
  • Part 4
    • Chapter 10, Discusses concepts around deploying ActiveMQ for production systems.
      • HA
      • Scalability
    • Chapter 11, Presents advanced features provided by ActiveMQ
      • Wildcards and composite destinations
      • Advisory messages
      • Virtual topics
      • ActiveMQ plugins
      • Message routing with Apache Camel
    • Chapter 12, Covers advanced ActiveMQ client features
      • Exclusive consumers
      • Message groups
      • ActiveMQ streams
      • Large objects
      • Failover transport
      • Message scheduling
    • Chapter 13, Deals with performance tuning
      • Persistent versus non-persistent messages
      • Transactions
      • Embedded brokers
      • Tuning the wire level protocol
      • Tuning the TCP transport
      • Optimizations for message producers and message consumers.
    • Chapter 14, Finishes up by discussing the administration and monitoring of ActiveMQ.
      • JMX
      • JConsole
      • Command-line tools
        • XMPP
        • JConsole
        • Web console
      • Broker- and client-level logging.

ActiveMQ in Action (2)


  • Today, six or seven years after ActiveMQ was originally created, it's surprising how far and widely it is being used.
There is a dedicated page in ActiveMQ's website listing projects using ActiveMQ.
It's interesting that SpringSide is listed.
  • The versatility of not only ActiveMQ but also event-based systems has appealed to a very large audience of users and that appeal continues to grow.
Keyword: event-based. Yes, messaging system is the core of event-base system.

  • ActiveMQ provides many features beyond this spec and it has not stopped innovating.
It is good or bad? I don't know.

  • We did our best to keep this book up to date with ActiveMQ 5.4.1
  • We hope that, by reading this book, you will come to appreciate not only ActiveMQ but the concepts surrounding event-based systems.

ActiveMQ in Action

  • Enterprise message queuing is a concept that is not well understood by most software developers.
That's true.
  • ActiveMQ project has been successful in this endeavor by creating a MOM that is easy to install, administer, and utilize, while providing a large number of unique features.
I am curious of these unique features. And I hope the author could give me a list and ensure me understand why they are unique. Here is a link from ActiveMQ's website:
  • Apache ActiveMQ ™ -- Features
    • Active Groups
      • Active Groups is a dynamic collaboration framework so simplify message passing and shared state between members of the group. It is available in ActiveMQ 6.0
    • ActiveMQ Real Time
      • ActiveMQ Real Time is a sub-project of the popular Apache ActiveMQ messaging system but is designed specifically to meet the needs for low latency high throughput collaborative real-time applications.
    • Clustering
      • Clustering is a large area and often means different things to different people. 
      • We'll try to list the various aspects of clustering and how they relate to ActiveMQ
    • Command Agent
      • From 4.2 onwards Apache ActiveMQ allows you to communicate with a broker Command Agent to be able to perform administration queries and commands. This allows you to use the message bus itself to communicate with the message broker to list available queues, topics, subscriptions, to view metadata, browse queues and so forth.
    • Consumer Features
    • Destination Features
      • Composite Destinations
      • Configure Startup Destinations
      • Delete Inactive Destinations
      • Destination Options
      • Mirrored Queues
      • Per Destination Policies
      • Virtual Destinations
      • Wildcards
    • Discovery
      • ActiveMQ uses an abstraction called a Discovery Agent to detect remote services such as remote brokers. We can use discovery for JMS clients to auto-detect a Message Broker to connect to, or to provide Networks of Brokers
      • There are currently two kinds of discovery agent.
    • Enterprise Integration Patterns
    • Features Overview
      • Supports a variety of Cross Language Clients and Protocols from Java, C, C++, C#, Ruby, Perl, Python, PHP
      • full support for the Enterprise Integration Patterns both in the JMS client and the Message Broker
      • Supports many advanced features such as Message Groups, Virtual Destinations, Wildcards and Composite Destinations
      • Fully supports JMS 1.1 and J2EE 1.4 with support for transient, persistent, transactional and XA messaging
      • Spring Support so that ActiveMQ can be easily embedded into Spring applications and configured using Spring's XML configuration mechanism
      • Tested inside popular J2EE servers such as Geronimo, JBoss 4, GlassFish and WebLogic
      • Includes JCA 1.5 resource adaptors for inbound & outbound messaging so that ActiveMQ should auto-deploy in any J2EE 1.4 compliant server
      • Supports pluggable transport protocols such as in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports
      • Supports very fast persistence using JDBC along with a high performance journal
      • Designed for high performance clustering, client-server, peer based communication
      • REST API to provide technology agnostic and language neutral web based API to messaging
      • Ajax to support web streaming support to web browsers using pure DHTML, allowing web browsers to be part of the messaging fabric
      • CXF and Axis Support so that ActiveMQ can be easily dropped into either of these web service stacks to provide reliable messaging
      • Can be used as an in memory JMS provider, ideal for unit testing JMS
    • Horizontal Scaling
      • Scaling to tens of thousands of Queues in a single broker is relatively straightforward - but requires some configuration changes from the default.
    • Interceptors
      • ActiveMQ has a sophisticated interceptor stack so that you can attach whatever functionality you require into the broker in an easy way without complicating all of the other broker code. This has really helped us keep the code clean and modular while offering powerful extension points.
    • JMSUserID
      • It is sometimes useful to know the authenticated username of the sender of a message. This is not added by default but you can enable it by setting thepopulateJMSXUserID property on the broker via Java code
    • JMX
      • Apache ActiveMQ has extensive support for JMX to allow you to monitor and control the behavior of the broker via the JMX MBeans.
    • Logging a warning if you forget to start a Connection
      • A very common gotcha when working with JMS is forgetting to start the JMS connection, creating a consumer and not having it receive any messages. I myself have tripped up over this one many many times!
    • MDC Logging
      • As of version 5.5.0, ActiveMQ uses slf4j as the logging framework. This allows us to support MDC logging.
    • Message Dispatching Features
      • Async Sends
      • Dispatch Policies
      • Message Cursors
      • Optimized Acknowledgement
      • Producer Flow Control
      • Total Ordering
    • Message Features
      • ActiveMQ Message Properties
      • Advisory Message
      • Blob Messages
      • Delay and Schedule Message Delivery
      • JMS Streams
      • Message Transformation
      • Structured Message Properties and MapMessages
    • New Features
      • This page documents the various new features we add in each major release
      • New Features in 6.0
      • New Features in 5.5
      • New Features in 5.4
      • New Features in 5.2
      • New Features in 5.1
      • New Features in 5.0
      • New Features in 4.1
      • New Features in 4.0
    • Performance
      • Performance differs greatly depending on many different factors
        • the network topology
        • transport protocols used
        • quality of service
        • hardware, network, JVM and operating system
        • number of producers, number of consumers
        • distribution of messages across destinations along with message size
      • To give you an idea of the kinds of performance you can expect from ActiveMQ we have a bunch of JMeter Performance Tests that you can run on your hardware with the protocols of your choice.
    • Persistence
    • Scaling the Depth of a Queue
      • Nearly all messaging systems (certainly open source ones) hold either a copy of a persistent message or a reference to a persisted message in memory. This is primarily to try and improve performance, but it also can significantly decrease the complexity of implementation. In fact ActiveMQ version 4 and below worked this - way - by holding references to persisted messages in memory.
    • Security
      • ActiveMQ 4.x and greater provides pluggable security through various different providers.
      • The most common providers are
        • JAAS for authentication
        • a default authorization mechanism using a simple XML configuration file.
    • The JMS Connector
    • The Proxy Connector
      • Many of the more advanced ActiveMQ features are implemented in the transports. Sometimes it's desirable to accept one kind of ActiveMQ connection and establish a different kind of connection to another broker. The Proxy Connector allows you to do that by accepting connection on one transport and establishing new connections using a different transport and then just proxying all the commands sent between the two transports.
    • Unix
    • URI Protocols
      • ActiveMQ is designed to support mutliple different topologies and protocols. Which one you use depends on your messaging requirements, quality of service and network topology.
      • The following table describes the different network protocols available along with showing the connection URL string you use to enable this communication protocol. You can specify the connection URL on anActiveMQConnectionFactory (in a constructor or via the brokerURL property).
    • Visualisation