/dev/websphere

GitHub for WebSphere eXtreme Code samples from my blog

I've been working on adding samples to github over the holidays. The wxsutils package has a fair bit of sample code around using agents and exposes some simplified primitives such as bulk get/put/remove operations. Just grab the jar and put on the classpath and then create a WXSUtils instance providing your client grid as the constructor parameter. Then you can call the getAll, putAll or removeAll methods for bulk operations.

The redis-wxs package is an implementation of a redis like API for WebSphere eXtreme Scale. It has a database (mysql or db2) with a fixed schema. There is a WXS grid running in front of the database. This is a collection of JVMs which act as a read-through write-behind cache on the state in the database. Client applications interact with this grid.

The clients can work with the grid using a very simple API. The grid basically allows the storage of:

• string/string pairs
• string/long pairs
• long/string pairs
• long/long pairs

It also allows lists and sets of strings or longs with string keys. The lists and sets have efficient primitives to make working with lists and sets easy. Lists have push operations which add new data to the left or right of the list. Pop operations remove items from the left or right. Trim operations reduce the size of the list. The range operation fetches a consecutive series of entries between two indexes from the list.

Set operations are also supported in that you can have a named set of Long values.

All data is stored ultimately in the database through the grid.

You can find the code at my github page

Tip of the century: Instrument your code with JMX

We got a lot of questions from customers on performance. The application is slow and we want IBM to help. Usually the first question is whats slow and nobody knows. The application was written with no builtin monitoring at all. The product monitoring can be useful but sometimes application specific metrics are much more useful.

IBM WebSphere eXtreme Scale includes monitoring but I met with Tom Lubinski from SL.com at QCon and he said that all samples should create MBeans and thus be monitorable. Many customers simply copy samples so this would mean more customer applications would have monitoring. So, here is the PureQuery Loader for WebSphere eXtreme Scale with monitoring.

I create a single MBean for each Map in a JVM. This MBean tracks statistics on the Loader for that Map. The purequery Loader uses classes from the purequery.jmx package but you can modify your Loader to make the same calls and get the same monitoring. You can do this with your own Loader pretty easily. Typically, add 3 calls for the start time, log exceptions and log the time in the operation.

I used JConsole to just connect to a container or test JVM and then I can see the beans for each Map, click on attributes and there are all the statistics. Here is an example of what it looks like in JConsole

 

You can see how many of each type of operation happened, how long the min/avg/max time is in milliseconds. How many exceptions? The string of the last exception and so on. This is very useful and adds almost no overhead to the running application. This kind of instrumentation in your application will save you a lot of time when performance isn't what you expected. It's easy to add, adds almost no performance overhead (when done with fast code, no sync blocks and so on). Just do it.

I'm in the process now of modifying the Chirp sample application to have MBeans for the client side/agent calls the application uses and the Loader code above. It makes the application much more demo-able as well as easier to find issue when they arise.

The source code for the instrumented PureQuery Loader with some framework classes are attached here.

New version which is thread safe: Download JMXLoaderSampleV2

Old version which had thread safety issues, sorry I was lazy :) (remains to compare with updated one)

Download JMXLoaderSample

IBM DB2 Purescale is very cool, IBM WebSphere eXtreme Scale makes it better

DB2 Purescale is announced now and it's pretty cool, they have worked for a long time on this and it looks like a great achievement by the folks in DB2 land. It's a scale out SQL database based on p-series hardware for now and the new cluster accelerator component. The cluster accelerator component is very similar to the coupling facility on z-series. As a result, DB2 Purescale is very similar to the design of DB2/390.

However, it's primary competitor is Oracle RAC. It's a very different design than Oracle RAC in that it does actually scale out well. RAC uses a peer to peer model for coordinating between its nodes that leads to performance bottlenecks under non application partitioned read/write transactional workloads. As a result, it appears most Oracle customers use RAC simply for 2 node hot failover. It's a solution for high availability, not scale out...

DB2 Purescale is different. Instead of trying to have each node coordinate with every other node, they centralized elements of this communication to the cluster accelerator. Centralized sounds slower but its not here. The peer to peer model results in more operations for coordination, all nodes are involved in the coordination function. The centralized one is much less as there is only one node handling this. Big difference, reduces coordination latencies significantly and this means better scaling. Of course, the cluster accelerator will slow down gradually as the cluster scales out but you end up being able to scale significantly more with this approach than the peer to peer approach. It's unlikely in practice customers will hit the limits.

Customers should also choose Purescale over previous solutions like DB2 HADR or queue replication for HA because the second box is actually contributing to the workload. 2 boxes gives higher performance than a single box with a passive replica. But, replication between data centers will still require technologies like queue replication and so on as all purescale nodes need to be on the same high performance network and SAN.

So customers can, of course, use PureScale for 2 node hot failover like Oracle RAC customers do but they will also be able to use it to build larger scale out databases and unlike Oracle RAC it will perform and scale up well. This will let customers build larger N node database clusters with hot failover and get very reasonable scaling. This may mean customers that previously looked at sharded databases might view purescale as an alternative to sharding as it will still look like a single database but operationally a sharded database (i.e. a manually partitioned set of independent databases) may be better from a risk point of view because the shards are independent and scale forever where as there is a limit for purescale but for most customers the limit will not be a factor. Purescale should give many customers looking at sharding a great alternative for scale out without the hassles of partitioning. Plus, there is no reason why a pair of Purescale nodes would be a shard. Each shard still needs to be highly available and if a shard gets really hot then you can add a node to the shard which is impossible with a conventional database. DB2 Purescale solves the hot shard problem nicely.

Does this mean there is no need for caching products like WebSphere eXtreme Scale? Of course not. Lets examine why:

• It's still an SQL database. You needed caches before for SQL databases, you still need caches for DB2 Purescale databases.
• IBM is not giving away DB2 purescale for free. It runs on Enterprise class servers with a SAN and very high speed networks. Companies will get significant value from buying Purescale and as a result they will want to extract the best value from it also. This means they will want to cache data in front of it just like they would have using an SMP database. Nothing has changed.
• Data is served up in SQL form and for many applications then needs to be object relationally mapped to objects. This means complex SQL to the database which is slow and lots of path length doing the actual mapping to objects in the application. Products like IBM WebSphere eXtreme Scale cache data in the native application form, this makes it significantly faster to fetch from the cache rather than fetching from a database and reduces the path on the application side because there is no mapping.
• You can't collocate your application with your data. The data will still be in a separate tier just like todays databases. 
• It's a single data center technology. The communication between the nodes and the cluster accelerator require a very high speed, low latency network and access to a SAN for best performance. You will only be able to use a purescale cluster within a single data center or possibly within a single network switch for best performance. Products like IBM WebSphere eXtreme Scale have deployed/proven out of the box multi-data center (more than 2) active/active capabilities.
• Customers used caches to reduce response times to access data. While DB2 purescale absolutely scales out horizontally extremely well, each operation still does a small amount of communication with the cluster accelerator. This is work that isn't needed with a normal single node database. This means slightly slower response times so if you needed to cache before for response times then nothing has changed with purescale.
• It's not a cost effective place to store short lived persistent data like application/http sessions or data related to application-customer conversations. Products like IBM WebSphere eXtreme Scale are designed to meet these needs in a more cost effective manner.

Most of this is not specific to purescale. These points apply to all databases, even mysql. These are the reasons customers used caches with databases or replaced databases with caches already. So, I hope we sell a truckload of DB2 purescale with a truck load of IBM WebSphere eXtreme Scale in front of it.