Archive for the ‘c++’ Category

Your tax dollars at work (c++ developers)

Wednesday, January 2nd, 2008

There’s some nice public domain code out there written by government contractors from projects like the human genome project… This once in particular is a nice toolkit for distrbuted programming in c++…

http://www.ncbi.nlm.nih.gov/IEB/ToolBox/CPP_DOC

It has some nice libraries for date math, asn.1 encoding, berkeleydb wrapper, sql database wrapper, fastcgi, etc…

Finally us geeks get something we can use from all the taxes we pay…

[del.icio.us] [Digg] [dzone] [Google] [Mixx] [Reddit] [StumbleUpon]
Writen by jake

Half-Asynch / Half-Synch Processing Model Added to Thrift

Sunday, June 10th, 2007

Synchronous processing and asynchronous processing have different strengths and weaknesses. Asynchronous processing is often confusing to system developers, but it scales really well. Synchronus processing (i.e. multi-threaded) is easy to add into a traditional program but is often resource intensive.

A good analogy of Asynch vs Synch programming is writing a SAX XML parser vs a DOM parser… DOM is easy to code but heavyweight. SAX is more complicated to code since but way faster and less resource intensive.

When it comes to web services they need to be able to support many simultaneous clients and perform complicated backend processing.

A great backend component we’ve mentioned before is memcached. This uses asynchronus processing so it can support tens of thousands of connections and is extremely fast because it’s actual work it to store and retrieve data from an in memory hash table.

But sometimes you need to perform processing intensive requests like searching a large index or image processing… to do this using an asynchronous processing model would be tricky and ineffective. At the same time, reading and writing the request over a socket using a synchronous processing model (one thread per request) would be a waste (imagine 200 56k clients connecting to you at the same time, that means 200 threads). The best solution is to perform the network IO using asynchronous processing and request processing using multiple threads (synchronus processing).

The ACE toolkit defined this design pattern years ago and I’ve used it quite effectively in the past however ACE is a very heavyweight only c++ library and its learning curve is pretty steep. This is why we are using thrift instead, since its interoperable with many languages and contains a lightweight c++ toolkit.

We are building some pretty cool web services using Thrift we recently worked with facebook to implement Half-Synch/Half-Asynch support to its c++ toolkit. As a result we can now support thousands of long lived connections while processing requests in a large thread pool.. Best of both worlds!

[del.icio.us] [Digg] [dzone] [Google] [Mixx] [Reddit] [StumbleUpon]
Writen by jake

memcache++ - a c++ client for memcached

Saturday, June 2nd, 2007

I’ve been using memcached for a couple years now and it’s by far one of the most useful open source tools. It’s written by Brad Fitzpatrick of livejournal, and used by everyone from, yahoo to facebook.

It so good because does one thing and it does it very well: It provides a distributed in memory cache.

Its super fast and super reliable, and it makes speeding up your site or application simple.

The server is written in c and uses libevent which is an highly scalable, asyncronous event based polling library which allows it to support tens of thousands of concurrent connections.

The client protocol is compact and there are clients in almost every language. The client libraies do most of the work since they can compress the data that goes into memcached and maintain multiple connections to different memcached instances running on your network (this is why the cache is distributed).

One of the few problems I’ve had with memcached have todo with the c based memcache clients libmemcache and apr_memcache.

libmemcache has problems corking the socket in linux, since it’s written for bsd. I’ve had reliability problems under high load where the client garbles the protocol.

apr_memcache works but the memcached protocol isn’t fully supported and it requires apr, which is a dependancy I’d rather not build into a non apache service.

Plus, I really wanted a OO api to use since I’m writing in c++ not c.

So I built memcache++ about a year ago, based origionally on a now defunct c++ client called memcachedpp.

Now that we have launched third rail, I now have a place to release memcache++ so grab it here:

http://3.rdrail.net/code/memcache++

Please send me a mail if you have problems with it, or if you are using it. I’m using it on a few projects with great success!

-Jake

[del.icio.us] [Digg] [dzone] [Google] [Mixx] [Reddit] [StumbleUpon]
Writen by jake