The holiday shopping season is upon us, with Black Friday and Cyber Monday just around the corner. Last year, shoppers spent over $655.8 billion during Black Friday and that amount is expected to increase by 47% this year. And during Cyber Monday last year, shoppers spent a record-breaking $3.45 billion, a 12.1% increase from the previous year.
Welcome back! Following the series about new batch features in Mule 3.8, the second most common request was being able to configure the batch block size.
What’s the block size?
In a traditional online processing model, each request is usually mapped to a worker thread. Regardless of the processing being synchronous, asynchronous, one-way, request-response, or even if the requests are temporarily buffered before being processed (like in the Disruptor or SEDA models),
We often get asked to help tune applications running on Mule for optimal performance. Over time, we have developed a methodology that helps us deliver on that request — and we wanted to share that methodology with you.
To-Do Before Tuning
Here are a few questions to ask before tuning. Performance tuning requires affirmative answers for (1) and (2), plus a concise response to (3).
- Does the application function as expected?
Data transformation is a core requirement for most integrations. Anypoint Platform provides multiple types of transformers, including XSLT, DataWeave and DataMapper.
DataWeave, our new data query and transformation language, offers significant performance advantages over Anypoint DataMapper, our earlier data mapping and transformation solution. The below benchmark shows transformations performance using DataWeave and Anypoint DataMapper with payload size of 100KB (1000 records) with simple complexity.
When deployed as an API Gateway and managed with API Manager, the highly performant Anypoint Platform enables you to control which traffic is authorized to pass through your APIs to various backend services, meter the traffic flowing through your API, log transactions, and apply runtime policies.
A policy is a mechanism the gateway uses to enforce filters on traffic as it flows through the gateway.
Currently, Mule relies on plain old java serialization in order to store objects to files or to replicate them through a Mule cluster. That imposes limitations on:
This is a follow up to the last post in which we discussed performance improvements on our XPath functionality obtained from the revamped XPath and XSLT support in Mule 3.6. This time, we’ll go through the same exercise but for the XSLT use case.
Just like with XPath, we worked with Luciano Gandini from the performance team. He came up with a test in which he measures the transactions per second (TPS) and latency of two XSLT transformations which inverts the tags of an XML.
This character is QuickSilver and he’s the fastest of the X-Men. Mule 3.6 has no super powers, but when it comes to XPath, it’s the fastest ever! As you may remember, with the release of Mule 3.6.0 the XPath and XSLT was revamped. In this post, I’d like to not only continue elaborating on how great the improvement is, but also focus on a new aspect: Performance.
Sometimes (more often than we think), less concurrency is actually more. Not too long ago, I found myself in a conversation in which we were discussing non-blocking architectures, tuning, and performance. We were discussing that tuning for those models often starts with “2 threads per core” (2TPC). The discussion made me curious about how Mule’s batch module would perform if tested by 2TPC. I knew beforehand that 2TPC wouldn’t be so impressive on batch, mainly because it doesn’t use a non-blocking threading model.
You might have read Dan Diephouse’s post last month announcing the release of Mule 3.6, and if you haven’t – go read it! And then come back to this. Seriously.
Ok, so now that you’ve read about the new HTTP connector in Mule 3.6 and seen the cool demo that Dan put together it’s my turn to drill down into some of the more interesting details – why we built the new connector,