OblakSoft
performance
WordPress on S3: now with CDN
OblakSoft is pleased to announce the release of the 1.1.x version of the WP2Cloud WordPress plugin. This release allows using a Content Distribution Network (CDN), such as Amazon CloudFront, to make content delivery even faster.
The WP2Cloud WordPress plugin now has an option to specify a Content Distribution URL. When the URL is specified, WP2Cloud redirects cloud storage URLs to point to the CDN. The CDN then serves the media files from locations around the world to provide the best performance.
The CDN must be configured correspondingly, so that it uses the cloud storage as the origin. The step-by-step instructions to configure Amazon CloudFront for WordPress on S3 / Yapixx are available here:
WordPress on S3 / Yapixx AMI with CDN support is available for FREE at http://www.oblaksoft.com/downloads/.
See also
WordPress on S3: run a beautiful website on Amazon cloud storage.
WordPress on S3: how it works.
WordPress on S3: run it anywhere.
WordPress on S3: no more backups.
MySQL on S3: performance with storage located across the continent
Can OLTP database workloads use Amazon S3 as primary storage? Now they can, thanks to the Cloud Storage Engine (ClouSE), but the question is: how fast?
MySQL BLOB meets Amazon S3: Weblobs explained
Cloud-powered BLOB type provides ACID guarantees and fast direct access to blobs via Web URLs.
Storing unstructured data
Typically unstructured data (such as pictures, media files, documents)
a) Is either stored on the file system, unlike the related with it relational data which is stored in the database. This is well known, “convenient” practice that allows fast access to files but offers no transactional story and no unified data management (for db and filesystem)
b) Or is stored in BLOBs. This ensures transactional consistency and reduces management complexities, but is really bad for performance and scalability.
We took advantage of the cloud, and came up with an upgrade to the BLOB – a solution that combines the benefits of the two.
(more…)
“WordPress on Amazon S3″, OblakSoft Cloud Storage Newsletter, May 2012
WordPress on S3: run a beautiful website on Amazon S3 cloud storage
OblakSoft is proud to introduce the 1st ever dynamic WordPress site running on top of Amazon S3: Yapixx. Now you too can launch your own beautiful website on Amazon S3.
While Yapixx stands for Yet Another Picture Sharing Site, it is actually one of a kind. Yapixx is WordPress that was moved to run on top of Amazon S3 storage without changing a line of code in the WordPress core engine.
WebStor – new open source high performance API for Amazon S3
OblakSoft is pleased to announce the release of WebStor 1.0b.1.1– the library providing high-performance cloud storage access.
WebStor is used in ClouSE – the Cloud Storage Engine for MySQL. ClouSE makes cloud storage to be a drop-in replacement for local storage. The outmost efficient and reliable cloud storage access is one of the key requirements that make the solution viable.
We’ve got a lot of questions about how ClouSE achieves such a great performance working with cloud storage. Cloud storage has a perception of being slow, but ClouSE works with cloud storage as fast as with local storage. WebStor is one of three pillars for high-performance cloud storage access (compression and caching are the other two).
In our benchmarks we were able to achieve up to 80+ MB/s transfer rate with Amazon S3. While ClouSE needs much, much less than that, thanks to compression and caching, when push comes to shove, WebStor is up for the job.
Here is the WebStor performance benchmark chart for transferring data from / to Amazon S3:
@Introducing new type of benchmark
My comment to Introducing new type of benchmark.
I’ve used Poisson load generators for blackbox perf testing of how the system responds to requests produced by independent irregular sources. The gist of a load generator is that it must generate the load with a given intensity regardless of the system response rate (compare to throughput measuring benchmarks: they don’t issue another request until they get a reply from the system, so their intensity is throttled by the system response rate). This is similar to what you describe in this post (though it looks like you still throttle the intensity on the client by spinning only N threads; my load generators would just keep generating requests with a given intensity spinning up as many threads as needed).
For whitebox perf testing, I usually use two simple benchmarks and then apply a simplified model that works pretty well. The two measurements are:
(more…)