Personal blog of Yzmir Ramirez

WordPress, the ubiquitous publishing platform that launched millions of blogs and websites, turned 20 on May 27th. While not the first open source content management system (CMS), WordPress caught on like nothing before and helped spread open source to millions.

It was simple, easy to deploy, and easy to use, and WordPress had the added benefit of being open source. WordPress also benefited from and popularized MySQL, introducing the LAMP stack – and open source – to an audience that might never have touched a database before or had any intro to open source.

Two great tastes that go great together

MySQL was around long before WordPress, and WordPress wasn’t the first CMS to use MySQL. MySQL was founded in 1995 and went open source in 2000. MySQL was the database for phpWebLog, for example, way back in 2000.

But WordPress brought MySQL and open source to the masses. WordPress arrived on the scene as blogging was becoming a mainstream trend and helped launch, literally, millions of blogs. As a side-effect, WordPress drove the deployment and use of MySQL by users well beyond the developer and database administrator (DBA) audiences.

While not the first open source LAMP stack CMS, WordPress made setting up a blog super simple. As WordPress evolved, its setup continued to get simpler and easier, but even the very first release reduced the complexity of deploying the blog along with its MySQL database.

MySQL knowledge (kind of) required

WordPress reduced complexity – but didn’t eliminate the need to interact with MySQL directly. And MySQL was the only option. If you wanted WordPress, you had to use MySQL. Even today, the defaults are MySQL 5.7 or later or MariaDB 10.3 or later.

The project signaled intent to support other databases as early as the 0.7.1 release, but support for non-MySQL databases never materialized. Why? Because there was never a compelling enough reason to do the work. MySQL filled the bill just fine.

Depending on your hosting setup and support, early WordPress deployments required a little bit of MySQL CLI work or using phpMyAdmin to create a database with a username and password for WordPress to connect.

And if you wanted to migrate hosting or back up your WordPress install? Time to get comfortable with MySQL backups. Today it’s possible to export your WordPress data with its export utilities through the Web interface. But, for a long time, you needed to be comfortable with mysqldump or other backup / restore methods to move servers or providers.

This meant many non-technical users had to learn a bit of MySQL to dump their WordPress database and restore it.

And if your blog got Slashdotted or just a high level of traffic in general? Then you might need to delve into MySQL tuning and replicas. Out of the box, MySQL was fine for a decent amount of traffic but would fall over pretty quickly if hit with a sustained burst of traffic.

Not because MySQL wasn’t performant but because the out-of-the-box defaults weren’t adequate for heavy traffic. With a little tuning, though, MySQL could hold its own.

MySQL (and open source) for the masses

In addition to exposing millions of bloggers to MySQL, WordPress helped make open source a mainstream concept.

Technical audiences were already discovering and singing the joys of open source. Developers, system administrators, database administrators, and enthusiasts were hip deep in open source operating systems, programming languages, and open databases like MySQL and PostgreSQL. But mainstream users? Not so much.

Firefox wouldn’t see its first release until November of 2004 and didn’t start seeing widespread adoption until years later. OpenOffice was around but not seeing a ton of traction.

But WordPress? It was a perfect project to promote open source to the masses. It was easy to use. Users didn’t have to upend their daily driver operating system. They didn’t have to re-learn an office suite. Demand for a CMS was relatively new, so few users were deeply attached to a proprietary alternative.

It demonstrated the values of open source and community. Note that I said values. It wasn’t just free, as in beer; it demonstrated the benefits of having access to source code. Lots of people got their start tinkering with source code, modifying WordPress, or writing plugins for it.

It showed the benefit of real open because you could host WordPress with any provider that would support it. Unhappy with your hosting provider? No problem. Migration between hosts was almost trivial using WordPress. 

WordPress, and the LAMP stack underneath it, was great for hosting providers too. No proprietary operating system or database required. You could cram servers full of users with their own small slice of resources for cheap. (Sometimes too many. Many of us learned to choose providers with a virtual private server with dedicated resources over shared hosting, but that’s another discussion for another day…)

WordPress made the web more manageable

Simply put, WordPress made the web more manageable, which also made it more open. While it started out as a blogging platform, it didn’t take long before people pressed it into service for entire sites. Why? Because it was easy, simple, ubiquitous, and free.

And, under the covers, MySQL (and MariaDB later on) helped make it possible. I’d argue that WordPress’s popularity was greatly helped by MySQL, while WordPress also brought MySQL to a new audience.

MySQL was performant enough to support heavily trafficked blogs and websites. It was open, which meant it could spread like wildfire without any licensing friction.

It was simple enough to administer, allowing inexperienced users to do basic DBA tasks like creating and backing up their WordPress database without needing much help. Experienced MySQL admins could tune MySQL to handle the heavy traffic loads for more popular sites.

Here’s to the next 20

In case it’s not blatantly obvious, I’m a big fan of WordPress. But not just a fan; I’ve been using it almost since the beginning for my own sites and others. I recommend it to anyone starting their own blog or site if they don’t have a strong use case for specific things WordPress doesn’t do well. You probably won’t be shocked to learn that Percona uses MySQL for its website, too.

Along the way, I’ve developed a great fondness for MySQL, too. (I was already a fan of Linux well before WordPress existed…)

The LAMP stack is still the foundation of the modern web. Depending on who’s doing the counting (and how), you’ll see WordPress credited with something like 43% of all websites and a whopping 65% of the CMS market. (As of May 2023; those numbers will no doubt change over time.) And where you find WordPress, you’ll find MySQL (or MariaDB), which means MySQL is also powering an enormous chunk of the Web.

With two decades under its belt, I feel like the best is still yet to come for WordPress. Here’s to the next 20; I can’t wait to see what’s next.

Percona Distribution for MySQL is the most complete, stable, scalable, and secure open source MySQL solution available, delivering enterprise-grade database environments for your most critical business applications… and it’s free to use!

 

Try Percona Distribution for MySQL today!

Automattic, the for-profit company tied to open-source web publishing platform WordPress, is announcing that it has acquired analytics provider Parse.ly.

Specifically, Parse.ly is now part of WPVIP, the organization within Automattic that offers enterprise hosting and support to publishers, including TechCrunch. (We use Parse.ly, too.)

WPVIP CEO Nick Gernert described this as the organization’s first large enterprise software acquisition, reflecting a strategy that has expanded beyond news and media organizations — businesses like Salesforce (whose venture arm invested $300 million in Automattic back in 2019), the NBA, Condé Nast, Facebook and Microsoft now use WPVIP for their content and marketing needs.

Both companies, Gernert said, come from similar backgrounds, with “roots” in digital publishing and a “heavy focus on understanding the impact of content.”

“We’ve really started to shift more towards content marketing and starting to think more deeply beyond just what traditional page analytics provide,” he continued. That means doing more than measuring pageviews and time on site and “really starting to look more deeply at things like conversation, attribution, areas … that from a marketer’s perspective are impactful.”

WordPress and Parse.ly already work well together, but the plan is to make WPVIP features available to Parse.ly customers while also making more Parse.ly data available to WPVIP publishers. And Gernert said there are also opportunities to add more commerce-related data to Parse.ly, since Automattic also owns WooCommerce.

The goal, he said, is to “make Parse.ly better for WordPress and best for WPVIP.”

At the same time, he added, “There’s no plans here to make Parse.ly the only analytics solution that runs on our platform. We want to preserve the flexibility and interoperability [of WordPress], and we want to make sure from a Parse.ly perspective that it still exists as a standalone product. That’s key to its future and we will continue to invest in it.”

Parse.ly was founded in 2009 and has raised $12.9 million in funding from investors including Grotech Ventures and Blumberg Capital, according to Crunchbase. Parse.ly founders Sachin Kamdar and Andrew Montalenti are joining WPVIP, with Kamdar leading go-to-market strategy for Parse.ly and Montalenti leading product.

“We’ve always had deep admiration for WPVIP’s market position as the gold standard for enterprise content teams, and we’re thrilled to be able to join together,” Kamdar said in a statement. “From the culture and people, to the product, market and vision, we’re in lockstep to create more value for our customers. This powerful combination of content and intelligence will push the industry forward at an accelerated pace.”

The financial terms of the acquisition were not disclosed.

WordPress.com, a division of Automattic, is launching a new product called P2. And this time, it’s all about improving internal communications for private groups. As a remote company, Automattic has been using P2 internally for years to communicate asynchronously. It’s a place to share long-form posts, a repository to keep onboarding documents and other important evergreen documents.

P2 is built on top of WordPress . You can view it as a sort of WordPress for teams that is heavily customized around the concept of sharing ideas with other team members. Companies now rely on multiple internal communication tools. P2 can replace some of them but doesn’t want to reinvent the wheel altogether.

For instance, P2 isn’t a Slack competitor. You can’t use it for real-time chat. But P2 can be used to share important announcements — the kind of announcements that you can find on an intranet portal.

You can also use it for long-term projects and create your own P2 for your team in particular. In that case, P2 competes more directly with Workplace by Facebook or Yammer. In order to make it more useful for asynchronous communications, P2 has some features that make it more useful than a simple WordPress blog.

For instance, you can @-mention your co-workers to send them a notification and follow posts to receive updates. You can also create checklists, embed PDF documents, stick important posts at the top of the homepage and stay on top of what happened while you were gone. There are dedicated menus to view new posts, new comments and mentions you’ve received.

While you can theoretically access the classic WordPress back-end, you can write new posts, edit existing posts and write comments without ever leaving P2. The company uses the new block editor that lets you add headings, lists, video embeds and media in a visual way. It works a bit like Squarespace’s editor or Notion, and it makes a ton of sense to leverage the new editor right next to content you’re viewing, commenting on, etc.

For content that always remains relevant, you can create documents, which are pages without a specific publishing date and without comments. These documents are sorted in their own category and can be easily shared across a company. You can use documents for internal policies, guides or important contact information. Many companies rely on Google Docs and shared folders in Google Drive for this kind of document. P2 could potentially replace those shared folders and become the main information repository.

By default, P2 sites are private, but you can make them public in case you want to share updates on your product with clients or use P2 for public events.

If you’re familiar with the WordPress ecosystem, you might already know a WordPress theme called P2. The new P2 announced today is a new product that takes that idea to the next level. Automattic has been iterating on the concept and using it widely with its 1,300 employees across 912 internal P2 sites.

WordPress.com is going to offer hosted P2 instances. Anybody can create a P2 for free and invite other people. Eventually, WordPress.com plans to offer paid subscriptions for advanced features. In other words, P2 is going to be a software-as-a-service product. But there will be a self-hostable, open-source version in the future as well.

I played around with a few P2 instances, and the overall impression is that the complexity of WordPress remains hidden by default, which is a good thing. It’s a clean and focused product that would work particularly well in that spot between company-wide emails and announcements getting lost in Slack.

In September, Salesforce Ventures, the venture of arm of Salesforce, announced a hefty $300 million investment in Automattic, the company behind WordPress, the ubiquitous content management system (CMS). At the same time, the company was putting the finishing touches on Salesforce CMS, an in-house project it released last week.

The question is, why did it choose to do both?

One reason could be that WordPress isn’t just well-liked; it’s also the world’s most popular content management system, running 34 percent of the world’s 10 billion websites — including this one — according to the company. With Automattic valued at $3 billion, that gives Salesforce Ventures a 10 percent stake.

Given the substantial investment, you wouldn’t have been irrational to at least consider the idea that Salesforce may have had its eye on this company as an acquisition target. In fact, at the time of the funding, Automattic CEO Matt Mullenweg told TechCrunch’s Romain Dillet that there could be some partnerships and integrations with Salesforce in the future.

Now we have a Salesforce CMS, and a potential partnership with one of the world’s largest web content management (WCM) tools, and it’s possible that the two aren’t necessarily mutually exclusive.

 While apps continue to grow in popularity as a primary route for people to interface with the digital world, there remains a very significant role for the web, and today, a startup that helps businesses build and run websites, specifically on WordPress, has raised a very large round of money. WP Engine, which claims to be one of the world’s largest WordPress hosts, has raised $250 million… Read More

 One of the few new top-level domains that actually makes sense, .blog, is starting the process of registration. Automattic, which runs WordPress and a number of other useful web apps, owns .blog and is handling applications at get.blog and, confusingly, dotblog.wordpress.com. Read More

 Media Temple is launching a new enterprise-grade WordPress hosting solution today. That would be interesting by itself, but the twist here is that the company, which is owned by GoDaddy, is hosting this service on AWS. With this offering, Media Temple is combining its expertise in running WordPress installs with its (mt) One white-glove customer service offering, CloudTech Premier support,… Read More

ScaleArc recently hired Percona to perform various tests on its database traffic management product. This post is the outcome of the benchmarks carried out by me and ScaleArc co-founder and chief architect, Uday Sawant.

The goal of this benchmark was to identify ScaleArc’s overhead using a real-world application – the world’s most popular (according to wikipedia) content management system and blog engine: WordPress.

The tests also sought to identify the benefit of caching for this type of workload. The caching parameters represent more real-life circumstances than we applied in the sysbench performance tests – the goal here was not just to saturate the cache. For this reason, we created an artificial WordPress blog with generated data.

The size of the database was roughly 4G. For this particular test, we saw that using ScaleArc introduces very little overhead and caching increased the throughput 3.5 times at peak capacity. In terms of response times, response times on queries for which we had a cache hit decreased substantially. For example, a 5-second main page load became less than 1 second when we had cache hits on certain queries. It’s a bit hard to talk about response time here in general, because WordPress itself has different requests that are associated with different costs (computationally) and which have different response times.

Test description

The pre-generated test database contained the following:

• 100 users
• 25 categories
• 100.000 posts (stories)
• 300.000 comments (3 per post)

One iteration of the load contained the following:

• Homepage retrieval
• 10 story (post) page retrieval
• 3 category page retrieval
• Log in as a random user
• That random user posted a new story and commented on an existing post

We think that the usage pattern is close to reality – most people just visit blogs, but some write posts and comments. For the test, we used WordPress version 3.8.1. We wrote a simple shell script that could do these iterations using multiple processes. Some of this testing pattern, however, is not realistic. Some posts will always have many more comments than others, and some posts won’t have any comments at all. This test doesn’t take that nuance into account, but that doesn’t change the big picture. Choosing a random post to comment on will give us a uniform comment distribution.

We measured 3 scenarios:

• Direct connection to the database (direct_wp).
• Connection through ScaleArc without caching.
• Connection through ScaleArc with caching enabled.

When caching is enabled, queries belonging to comments were cached for 5 minutes, queries belonging to the home page were cached for 15 minutes, and queries belonging to stories (posts) were cached for 30 minutes.

We varied the number of parallel iterations. Each test ran for an hour.

Results for direct database connection

Threads: 1, Iterations: 180, Time[sec]: 3605
   Threads: 2, Iterations: 356, Time[sec]: 3616
   Threads: 4, Iterations: 780, Time[sec]: 3618
   Threads: 8, Iterations: 1408, Time[sec]: 3614
   Threads: 16, Iterations: 2144, Time[sec]: 3619
   Threads: 32, Iterations: 2432, Time[sec]: 3646
   Threads: 64, Iterations: 2368, Time[sec]: 3635
   Threads: 128, Iterations: 2432, Time[sec]: 3722

The result above is the summary output of the script we used. The data shows we reach peak capacity at 32 concurrent threads.

Results for connecting through ScaleArc

Threads: 1, Iterations: 171, Time[sec]: 3604
   Threads: 2, Iterations: 342, Time[sec]: 3606
   Threads: 4, Iterations: 740, Time[sec]: 3619
   Threads: 8, Iterations: 1304, Time[sec]: 3609
   Threads: 16, Iterations: 2048, Time[sec]: 3625
   Threads: 32, Iterations: 2336, Time[sec]: 3638
   Threads: 64, Iterations: 2304, Time[sec]: 3678
   Threads: 128, Iterations: 2304, Time[sec]: 3675

The results are almost identical. Because a typical query in this example is quite expensive, the overhead of ScaleArc here is barely measurable.

Results for connecting through ScaleArc with caching enabled

Threads: 1, Iterations: 437, Time[sec]: 3601
   Threads: 2, Iterations: 886, Time[sec]: 3604
   Threads: 4, Iterations: 1788, Time[sec]: 3605
   Threads: 8, Iterations: 3336, Time[sec]: 3600
   Threads: 16, Iterations: 6880, Time[sec]: 3606
   Threads: 32, Iterations: 8832, Time[sec]: 3600
   Threads: 64, Iterations: 9024, Time[sec]: 3614
   Threads: 128, Iterations: 8576, Time[sec]: 3630

Caching improved response time even for a single thread. At 32 threads, we see more than 3.5x improvement in throughput. Caching is a great help here for the same reason the overhead is barely measurable: the queries are more expensive in general, so more resources are spared when they are not run.

Throughput
From the web server’s access log, we created a per-second throughput graph. We are talking about requests per second here. Please note that the variance is relatively high, because the requests are not identical – retrieving the main page is a different request and has a different cost then retrieving a story page.

The red and blue dots are literally plotted on top of each other – the green bar is always on top of them. The green ones have a greater variance because even though we had caching enabled during the test, we used more realistic TTLs in this cache, so cached items did actually expire during the test. When the cache was expired, requests took longer, so the throughput was lower. When the cache was populated, requests took a shorter amount of time, so the throughput was higher.

CPU utilization

CPU utilization characteristics are pretty much the same on the left and right sides (direct connection on the left and ScaleArc without caching on the right). In the middle, we can see that the web server’s CPU gets completely utilized sooner with caching. Because data comes faster from the cache, it serves more requests, which costs more resources computationally. On the other hand, the database server’s CPU utilization is significantly lower when caching is used. The bar is on the top on the left and right sides – in the middle, we have bars both at the top and at the bottom. The test is utilizing the database server’s CPU completely only when we hit cache misses.

Because ScaleArc serves the cache hits, and these requests are not hitting the database, the database is not used at all when requests are served from the cache. In the case of tests with caching on, the bottleneck became the web server, which is a component that is a lot easier to scale than the database.

There are two more key points to take away here. First, regardless of whether caching is turned on or off, this workload is not too much for ScaleArc. Second, the client we ran the measurement scripts on was not the bottleneck.

Conclusion
The goal of these benchmarks was to show that ScaleArc has very little overhead and that caching can be beneficial for a real-world application, which has a “read mostly” workload with relatively expensive reads (expensive means that network round trip is not a significant contributor in the read’s response time). A blog is exactly that type – typically, more people are visiting than commenting. The test showed that ScaleArc is capable of supporting this scenario well, delivering 3.5x throughput at peak capacity. It’s worth mentioning that if this system needs to be scaled, more web servers could be added as well as more read slaves. Those read slaves can take up read queries by a WordPress plugin which allows this, or by ScaleArc’s read-write splitting facility (it threats autocommit selects as reads), in the later case, the caching benefit is present for the slaves as well.

The post ScaleArc: Real-world application testing with WordPress (benchmark test) appeared first on MySQL Performance Blog.