Personal blog of Yzmir Ramirez

Adobe today announced the launch of its Commerce Cloud, the newest part of the company’s Experience Cloud. Unsurprisingly, the Commerce Cloud builds on the company’s $1.68 billion acquisition of Magento last May. Indeed, at its core, the Adobe Commerce Cloud is essentially a fully managed cloud-based version of the Magento platform that is fully integrated with the rest of Adobe’s tools, including its Analytics Cloud, Marketing Cloud and Advertising Cloud.

With this launch, Adobe is also extending the platform by adding new features like dashboards for keeping an eye on a company’s e-commerce strategy and, for the first time, an integration with the Amazon marketplace from which users will be able to directly manage within the Commerce Cloud interface.

“For Adobe, that’s really important because it actually closes the last mile in its Experience offering,” said Jason Woosley, Adobe’s VP of its commerce product and platform and Magento’s former VP of product and technology. “It’s no mystery that they’ve been looking at commerce offerings in the past. We’re just super glad that they settled on us.”

Woosley also stressed that this new product isn’t just about closing the last mile for Adobe from a commerce perspective but also from a data intelligence perspective.”If you think about behavioral data you get from your interactions with our content, that’s all very critical for understanding how your customers are interacting with your brand,” he said. “But now that we’ve got a commerce offering, we are actually able to put the dollars and cents behind that.”

Adobe notes that this new offering also means that Magento users won’t have to worry about the operational aspects of running the service themselves. To ensure that it can manage this for these customers, the company has tweaked the service to be flexible and scalable on its platform.

Woosley also stressed the importance of the Amazon integration that launches with the Commerce Cloud. “Love it or hate it,” he said of Amazon. “Either you are comfortable participating in those marketplaces or you are not, but at the end of the day, they are capturing more and more of the initial product search.” Commerce Cloud users will be able to pick and choose which parts of their inventory will appear on Amazon and at what prices. Plenty of brands, after all, only want to showcase a selection of their products on Amazon to drive their brand awareness and then drive customers back to their own e-commerce stores.

It’s worth noting that all of the usual Magento extensions will work on the Adobe Commerce Cloud. That’s important given that there are more than 300,000 developers in the Magento ecosystem, plus thousands of partners. With that, the Commerce Cloud can cover quite a few use cases that wouldn’t be important enough for Adobe itself to put its own resources behind but that make the platform attractive for a wider range of potential users.

It’s been less than six months since Adobe acquired commerce platform Magento for $1.68 billion and today, at Magento’s annual conference, the company announced the first set of integrations that bring the analytics and personalization features of Adobe’s Experience Cloud to Magento’s Commerce Cloud.

In many ways, the acquisition of Magento helps Adobe close the loop in its marketing story by giving its customers a full spectrum of services that go from analytics, marketing and customer acquisition all the way to closing the transaction. It’s no surprise then that the Experience Cloud and Commerce Cloud are growing closer to, in Adobe’s words, “make every experience shoppable.”

“From the time that this company started to today, our focus has been pretty much exactly the same,” Adobe’s SVP of Strategic Marketing Aseem Chandra told me. “This is, how do we deliver better experiences across any channel in which our customers are interacting with a brand? If you think about the way that customers interact today, every experience is valuable and important. […] It’s no longer just about the product, it’s more about the experience that we deliver around that product that really counts.”

So with these new integrations, Magento Commerce Cloud users will get access to an integration with Adobe Target, for example, the company’s machine learning-based tool for personalizing shopping experiences. Similarly, they’ll get easy access to predictive analytics from Adobe Analytics to analyze their customers’ data and predict future churn and purchasing behavior, among other things.

These kinds of AI/ML capabilities were something Magento had long been thinking about, Magento’s former CEO and new Adobe SVP fo Commerce Mark Lavelle told me, but it took the acquisition by Adobe to really be able to push ahead with this. “Where the world’s going for Magento clients — and really for all of Adobe’s clients — is you can’t do this yourself,” he said. “you need to be associated with a platform that has not just technology and feature functionality, but actually has this living and breathing data environment that that learns and delivers intelligence back into the product so that your job is easier. That’s what Amazon and Google and all of the big companies that we’re all increasingly competing against or cooperating with have. They have that type of scale.” He also noted that at least part of this match-up of Adobe and Magento is to give their clients that kind of scale, even if they are small- or medium-sized merchants.

The other new Adobe-powered feature that’s now available is an integration with the Adobe Experience Manager. That’s Adobe’s content management tool that itself integrates many of these AI technologies for building personalized mobile and web content and shopping experiences.

“The goal here is really in unifying that profile, where we have a lot of behavioral information about our consumers,” said Aseem. “And what Magento allows us to do is bring in the transactional information and put those together so we get a much richer view of who the consumers are and how we personalize that experience with the next interaction that they have with a Magento-based commerce site.”

It’s worth noting that Magento is also launching a number of other new features to its Commerce Cloud that include a new drag-and-drop editing tool for site content, support for building Progressive Web Applications, a streamlined payment tool with improved risk management capabilities, as well as a new integration with the Amazon Sales Channel so Magento stores can sync their inventory with Amazon’s platform. Magneto is also announcing integrations with Google’s Merchant Center and Advertising Channels for Google Smart Shopping Campaigns.

During the last couple of months I have been involved in an unusually high amount of performance audits for e-commerce applications running with Magento. And although the systems were quite different, they also had one thing in common: the MySQL query cache was very useful. That was counter-intuitive for me as I’ve always expected the query cache to be such a bottleneck that response time is better when the query cache is turned off no matter what. That lead me to run a few experiments to better understand when the query cache can be helpful.

Some context

The query cache is well known for its contentions: a global mutex has to be acquired for any read or write operation, which means that any access is serialized. This was not an issue 15 years ago, but with today’s multi-core servers, such serialization is the best way to kill performance.

However from a performance point of view, any query cache hit is served in a few tens of microseconds while the fastest access with InnoDB (primary lookup) still requires several hundreds of microseconds. Yes, the query cache is at least an order of magnitude faster than any query that goes to InnoDB.

A simple test

To better understand how good or bad the query cache can be, I set up a very simple benchmark:

• 1M records were inserted in 16 tables.
• A moderate write load (65 updates/s) was run with a modified version of the update_index.lua sysbench script (see the end of the post for the code).
• The select.lua sysbench script was run, with several values for the --num-threads option.

Note that the test is designed to be unfavorable to the query cache as the whole dataset fits in the buffer pool and the SELECT statements are very simple. Also note that I configured the query cache to be large enough so that no entry was evicted from the cache due to low memory.

Results – MySQL query cache ON

First here are the results when the query cache is enabled:

This configuration scales well up to 4 concurrent threads, but then the throughput degrades very quickly. With 10 concurrent threads, SHOW PROCESSLIST is enough to show you that all threads spend all their time waiting for the query cache mutex. Okay, this is not a surprise.

Results – MySQL query cache OFF

When the query cache is disabled, this is another story:

Throughput scales well up to somewhere between 10 and 20 threads (for the record the server I was using had 16 cores). But more importantly, even at the higher concurrencies, the overall throughput continued to increase: at 20 concurrent threads, MySQL was able to serve nearly 3x more queries without the query cache.

Conclusion

With Magento, you can expect to have a light write workload, very low concurrency and also quite complex SELECT statements. Given the results of our simple benchmarks, it is finally not that surprising that the MySQL query cache is a good fit in this case.

It is also worth noting that many applications run a database workload where writes are light and concurrency is low: the query cache should then not be discarded immediately. And maybe it is time for Oracle to make plans to improve the query cache as suggested by Peter a few years ago?

Annex: sysbench commands

# Modified update_index.lua
function event(thread_id)
   local table_name
   table_name = "sbtest".. sb_rand_uniform(1, oltp_tables_count)
   rs = db_query("UPDATE ".. table_name .." SET k=k+1 WHERE id=" .. sb_rand(1, oltp_table_size))
   db_query("SELECT SLEEP(0.015)")
end

# Populate the tables
sysbench --mysql-socket=/data/mysql/mysql.sock --mysql-user=root --mysql-db=db1 --oltp-table-size=1000000 --oltp-tables-count=16 --num-threads=16 --test=/usr/share/doc/sysbench/tests/db/insert.lua prepare
# Write workload
sysbench --mysql-socket=/data/mysql/mysql.sock --mysql-user=root --mysql-db=db1 --oltp-tables-count=16 --num-threads=1 --test=/usr/share/doc/sysbench/tests/db/update_index.lua --max-requests=1000000 run
# Read workload
sysbench --mysql-socket=/data/mysql/mysql.sock --mysql-user=root --mysql-db=db1 --oltp-tables-count=16 --num-threads=1 --test=/usr/share/doc/sysbench/tests/db/select.lua --max-requests=10000000 run

The post The MySQL query cache: Worst enemy or best friend? appeared first on MySQL Performance Blog.

Oracle was in the news recently with the story of its license revenue declining as much as 17% in the recent quarter. This is blamed on transitioning to the cloud in some publications, but others, such as Bloomberg and TechRepublic, look deeper, seeing open source software responsible for the bulk of it.

Things are especially interesting in the MySQL ecosystem, as Oracle both owns its traditional “Enterprise” Oracle database and MySQL – a more modern open source database.

At Percona we see the same story repeating among many of our enterprise customers:

1. MySQL proves itself. This generally happens one of two ways. One is for the enterprise using traditional enterprise databases, such as Oracle or DB2, to acquire a company which has been built on MySQL. After the dust settles the CFO or CIO discovers that the acquired company has been successfully running business-critical operations with MySQL and spending hundreds of thousands of dollars on database support instead of tens of millions. At this point it’s been shown that it can be done, so it should continue.

The other way is for MySQL to rise through the ranks in an organization. Typically it starts with some small MySQL use, such as running a bug tracking application in the IT department. Then it moves to MySQL being used with Drupal to power the main corporate website and an e-commerce function with Magento or something similar. Over time, MySQL proves itself and is trusted to handle more and more “core” enterprise databases that are absolutely critical for the business.

Interestingly enough, contrary to what some people have said, MySQL ownership by Oracle helps it to gain trust with many enterprise accounts. Enterprises may not like Oracle’s license and maintenance fees, but they like Oracle’s quality engineering, attention to security and predictable releases.

2. New applications are built using MySQL. As the enterprise is ready to embrace MySQL it is added to the approved database list and now internal teams can use it to develop applications. In many cases the mandate goes even further with MySQL than with other open source technologies, as it is given preference, and teams need to really justify to management when they want to use Oracle or other proprietary database technologies. There are some cases when that may be warranted, but in most cases MySQL is good enough.

3. Moving existing applications from Oracle to MySQL.  Depending on the organization and applications it can happen a couple of different ways. One is the equivalent applications are built from scratch on the new open source technology stack and the old application is retired. The other is only the database is migrated from Oracle to MySQL. Moving the database from Oracle to MySQL might be easy and might be close to a full application rewrite. For example, we see Java applications which often use the database as a simple data store through the ORM framework which can be moved to MySQL easily; on the other hand, applications built with extensive use of advanced stored procedures and Oracle-specific SQL extensions are much harder to move.

The wave of moving to open source database technologies will continue and we’re not alone in thinking that – Gartner believes that by 2018, 70% of new in-house applications will be built on open source database systems.

What are we currently seeing in the MySQL ecosystem? First, many customers tell us that they are looking at hefty price increases for MySQL support subscriptions. Some of the customers which had previously signed 5 year agreements with Sun (at the time it was acquired by Oracle) who are exploring renewing now, see price increases as much as 5x for a comparable environment. This is very understandable considering the pressures Oracle has on the market right now.

The issues, however, go deeper than the price. Many customers are not comfortable trusting Oracle to give them the best possible advice for moving from expensive Oracle to a much less expensive Oracle MySQL database. The conflicts are obvious when the highest financial reward comes to Oracle by proving applications can’t be moved to MySQL or any other open source database.

If you’re choosing MySQL, Oracle is financially interested in having you use the Enterprise Edition, which brings back many of the vendor lock-in issues enterprises are trying to avoid by moving to open source databases. Customers believe Oracle will ensure enterprise-only features are put in use in the applications, making it difficult to avoid renewing at escalating prices.

So what do our customers see in Percona which makes them prefer our support and other services to those of Oracle?

• We are a great partner if you’re considering moving from the Oracle database to MySQL as we both have years of experience and no conflict of interest.
• Percona Server, Percona XtraDB Cluster, Percona Xtrabackup and our other software for the MySQL ecosystem is 100% open source, which means we’re not trying to lock you into the “enterprise version” as we work together. Furthermore, many of the features which are only available in MySQL Enterprise Edition are available in the fully open source Percona Server, including audit, backup and authentication.
• We are focused on solutions for your business, not pushing Percona-branded technology. If you choose to use Percona Server, great! If you are using MySQL, MariaDB, Amazon RDS, etc., that’s great too.

With the continuing trend of moving to open source database management systems the cost pressures on people running proprietary databases will continue to increase, and the only real solution is to accelerate moving to the open source stack. As you do that, you’re better off moving to completely open source technology, such as what is available from Percona, to avoid vendor lock-in. If you’re looking for the partner to help you to assess the migration strategy and execute the move successfully, check for conflicts of interests and ensure the interests of your and your provider are completely aligned.

The post Oracle license revenue and the MySQL ecosystem appeared first on MySQL Performance Blog.