Aug
06
2020
--

WordPress.com launches new P2 to take on internal communication tools

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.

Image Credits: WordPress.com

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.

Image Credits: WordPress.com

Nov
11
2019
--

Salesforce Ventures invested $300M in Automattic while Salesforce was building a CMS

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.

Jan
04
2018
--

WP Engine, a managed WordPress platform, raises $250M from Silver Lake

 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

Aug
23
2016
--

New .blog TLD opens up early registration applications

dotblog-social 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

May
17
2016
--

Media Temple launches new enterprise WordPress solution hosted on AWS

2016-05-16_1807 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

Apr
29
2014
--

ScaleArc: Real-world application testing with WordPress (benchmark test)

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.

throughput

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_util

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.

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com