• Choose a category
• All
• Classic-Fiction

By Root 720 0

generation to enable rapid development of software spanning multiple programming languages. Data types and service interfaces are defined in .thrift files, which use a simple, language-neutral grammar. The Thrift compiler then generates all the necessary plumbing code in the languages of your choice to encode and transport data objects and make service calls, letting the developer focus on writing the actual application code.

For example, suppose you have created a web frontend in PHP. You want to build a service to efficiently search an object store, and you’d like to build this service in C++ to optimize memory usage and data structure layout. Here’s how you might define such a service in Thrift:

search.thrift:

struct search_result_elem {

1: i64 object_id,

2: list terms.

3: i64 weight

}

struct search_result {

1: i32 total,

2: list matches

}

service search {

search_result query(1:list terms)

}

To generate all the framework code you need, you’d simply execute the following:

thrift -cpp -php search.thrift

Your C++ server stub is generated, and you just need to fill in the method implementation:

class searchHandler : virtual public searchIf {

public:

searchHandler() {

// Your initialization goes here

}

void query(search_result& _return, const std::vector & terms) {

// Your implementation goes here

printf("query\n");

}

};

Similarly, all your PHP client code is generated. To make a call to the service, you simply write the following:

function call_search() {

// Specify the server to connect to

$transport = new TSocket('192.168.1.1', '9090');

$transport->open();

// Pick the protocol you want to use

$protocol = new TBinaryProtocol($transport);

// Make a client for your service

$client = new searchClient($protocol);

// Make the call!

$results = $client->query(array('term1', 'term2'));

}

Thrift supports many advanced features, such as:

Service inheritance

Cross-language support for application-level exceptions

Compatibility across application version changes

Multiple encoding protocols (binary, JSON, etc.)

Multiple transport mechanisms (TCP sockets, files, HTTP)

Multiple server implementations (threaded, libevent, pooling)

For more information on Thrift, visit http://developers.facebook.com/thift/.

The Database Is Dead! Long Live memcached!

Problem

I’m designing a very database-intensive application that is going to need to do a lot of reads to render a page. I know this is going to get slow as the database fills up and I have a lot of users hammering on it, so what can I do to speed that up?

Solution

Use memcached, a caching application originally developed by Danga Interactive to speed up LiveJournal (http://livejournal.com) but now in use all over the Web (including YouTube, Slashdot, Wikipedia, SourceForge, Facebook, Digg, Twitter, and http://nytimes.com). Memcached is a sophisticated caching engine designed to quickly return results from memory instead of making a trip to your database, which makes it fast. In answer to the question, “Is memcached fast?”, Danga says:

Very fast. It uses libevent to scale to any number of open connections (using epoll on Linux, if available at runtime), uses nonblocking network I/O, refcounts internal objects (so objects can be in multiple states to multiple clients), and uses its own slab allocator and hash table so virtual memory never gets externally fragmented and allocations are guaranteed O(1).

That’s one of those blocks of text that you either understand on your own or, like me, have to read a few times before ultimately giving up and accepting that you can move on without knowing what a slab allocator is. You can find more information about memcached, as well as downloads, at http://www.danga.com/memcached.

Discussion

This is one of those places where it’s worth building in scalability from the beginning. Thanks to the memcached libraries available for most languages, implementing is really easy and won’t significantly slow down your initial