As traffic to cnbc.com continued to grow, we found ourselves in an all-too-familiar situation where one feels that a BIG change in how things are done was in order, the status-quo was a road to nowhere. The spending on HW, amount of space and power required to host additional servers, less-than-stellar response times, having to resort to frequent "micro"-caching and similar tricks to try to improve code performance - all of these were surfacing in plain sight, hard to ignore.

While code base could clearly be improved, the limited Dev resources and having to innovate to stay competitive always limits ability to go about refactoring. So how can one go about addressing performance and other needs without a full blown effort across the entire team ? For us, the answer was aiCache - a Web caching and application acceleration product (aicache.com).

read more

Te 24-hour has-patch marathon has just officially begun! For the next 24 hours (until Friday, 4pm UTC), the core developers will be evaluating patches that have been tested and committing those that are good. When they run out of those, they’ll start testing patches that have been submitted but not tested. This takes longer, so help us keep the momentum going by testing patches today.

Grab yourself a copy of the nightly build to make sure you’re using the right version, then head over to Trac and start looking at the has-patch* tickets. Pick a ticket, download the diff, test it out on the browsers/platforms you have available, and write a comment about the results in the ticket’s comment thread. Move on to the next ticket. Do as many as you can over the next 24 hours.

And if you’ve got the mad skills to contribute bug fixes and code patches for enhancements and other tickets, now is also a great time to contribute a patch. Why wait? One of the complaints I hear in the IRC #wordpress-dev channel is that it can be frustrating to write patches because sometimes it takes a long time for them to be reviewed and committed. For those people (and everyone else), this is the perfect time to patch, because we’ll be looking at every has-patch ticket in Trac for 2.8 over the next 24 hours. If you have a patch that’s been submitted but it hasn’t been tested, consider doing a little PR for yourself. Hop in the dev channel, post on your blog, mention on Twitter that you need people to test your patch *today* so that it can move forward in the process. This will speed things along. You can also add the keyword needs-testing in addition to has-patch.

At the end of the 24-hour period, you don’t have to put your pencils down, but the core devs will be going to sleep and then returning to the regular dev cycle, so it’s worth it to contribute today. If you miss the deadline, it’s okay; you can contribute or test patches as usual, you just won’t get the more immediate gratification the marathon promises.

We’ll post the results of the marathon here on Monday, after everyone’s gotten some rest and we can go through the Trac logs to see how many people got involved. This is one reason it’s so important to leave a comment when testing patches…it’s how we’ll be counting the number of marathon testers. Top patch contributors and testers will be recognized in the results post, so if that sort of thing motivates you, let the link love lead the way.

Of note: we are now in feature freeze for 2.8!

* - For those who don’t know why I keep using the term has-patch… When someone submits a patch by uploading it to the Trac ticket, they add “has-patch” to the keywords field, so that the core devs will know there’s a patch attached. Not the most elegant system, true, and you’d think maybe Trac could just recognize that a certain file type had been uploaded, but there you have it.

Update 3: A Comparison of Approaches to Large-Scale Data Analysis: MapReduce vs. DBMS Benchmarks. Although the process to load data into and tune the execution of parallel DBMSs took much longer than the MR system, the observed performance of these DBMSs was strikingly better.
Update 2: H-Store: A Next Generation OLTP DBMS is the project implementing the ideas in this paper: The goal of the H-Store project is to investigate how these architectural and application shifts affect the performance of OLTP databases, and to study what performance benefits would be possible with a complete redesign of OLTP systems in light of these trends. Our early results show that a simple prototype built from scratch using modern assumptions can outperform current commercial DBMS offerings by around a factor of 80 on OLTP workloads.
Update: interesting related thread on Lamda the Ultimate.

A really fascinating paper bolstering many of the anti-RDBMS threads the have popped up on the intertube lately. The spirit of the paper is found in the following excerpt:

In summary, the current RDBMSs were architected for the business data processing market in a time of different user interfaces and different hardware characteristics. Hence, they all include the following System R architectural features:
* Disk oriented storage and indexing structures
* Multithreading to hide latency
* Locking-based concurrency control mechanisms
* Log-based recovery

read more

月初就计划，要在四月的牡丹花期内带公婆去洛阳赏花。订票订房间安排好工作后，忽然接到公司给管理层的公费旅游通知，权衡半天毅然向公司告假：一是不忍让公婆失望，且让小宝独自照顾爸妈也怕他太累；二就是虽时间短，但对此次洛阳之行我仍非常期待。