- 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.
26.12.11
Java Performance - Ideal CPU Utilization?
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.
Java Performance - Choosing the Right Platform and Evaluating a System
- The application may be running on an inappropriate CPU architecture or system.
- Multiple cores per CPU
- Multiple threads per core (CMT, chip multithreading)
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.
- CPU Cache Missing
- 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. 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
- Communication <=> Notification
- Integration <=> Inter-operation
- Open Source Initiative (OSI)
- Connectivity
- IP Multicast
- SSL
- STOMP
- UDP
- XMPP
- Pluggable persistent
- Apache ActiveMQ ™ -- Persistence
- I don't see "Pluggable"
- JDBC-accessible
- Pluggable security
- Apache ActiveMQ ™ -- 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.
- Broker clustering
- Camel routes
- Monitoring
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.
- 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.
- ActiveMQ provides many features beyond this spec and it has not stopped innovating.
- 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.
- 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.
- 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
- Consumer Dispatch Async
- Consumer Priority
- Exclusive Consumer
- Manage Durable Subscribers
- Message Groups
- Redelivery Policy
- Retroactive Consumer
- Selectors
- Slow Consumer Handling
- Subscription Recovery Policy
- 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
- Version 5.0 onwards of Apache ActiveMQ comes complete with full support for the Enterprise Integration Patterns (from the excellent book by Gregor Hohpe and Bobby Woolf) via the Apache Camel library.
- You can easily add any of the supported Enterprise Integration Patterns into ActiveMQ (either on the JMS client or in the broker process) to support smart routing, transformation and a whole host of other powerful patterns. You can of course just embed Camel librarydirectly into your application, such as via Spring as well..
- This also means you can cleanly integrate all of the Camel Components into ActiveMQ so you can easily integrate with CXF, Files,JBI, JPA, Mail, MINA, Quartz, XMPP and many other protocols and transports!
- 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
- From 5.3 onwards - we recommend you use KahaDB - which offers improved scalability and recoverability over the AMQ Message Store.
- The AMQ Message Store which although faster than KahaDB - does not scales as well as KahaDB and recovery times take longer.
- 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
- This page contains resources that will make you adapt ActiveMQ to your Unix-based operating system.
- 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
- Inspired greatly by Gregor and Erik's great talk at TSSJS 2006 we've started to add some visualisation plugins into Apache ActiveMQ.