{"id":793,"date":"2008-04-15T20:04:08","date_gmt":"2008-04-16T01:04:08","guid":{"rendered":"http:\/\/www.bytebot.net\/blog\/archives\/2008\/04\/15\/services-oriented-architecture-with-php-and-mysql"},"modified":"2008-04-15T20:07:43","modified_gmt":"2008-04-16T01:07:43","slug":"services-oriented-architecture-with-php-and-mysql","status":"publish","type":"post","link":"http:\/\/www.bytebot.net\/blog\/archives\/2008\/04\/15\/services-oriented-architecture-with-php-and-mysql","title":{"rendered":"Services Oriented Architecture with PHP and MySQL"},"content":{"rendered":"

Joe Stump<\/a>, Lead Architect, Digg. Slides should make its way at Joe’s website soon enough.<\/p>\n

Mainly works on the backend, makes sure its scalable, can all the Digg buttons be served, et al.<\/p>\n

Application layer is loosely coupled from your data. Whole point of SOA? You can put a service in front of the DB, and move between DB’s if required.<\/p>\n

They do use MySQL, but its pretty vanilla.<\/p>\n

Old habits die hard<\/strong>
\n– Data requests are sequential (I need foo, bar, bleh, ecky)
\n– Data requests are blocking (When you need foo, nothing else is happening)
\n– Tightly coupled (mysql_query, and if you’re using DB abstraction layer even, you’re still using SQL… you then can’t use CouchDB for instance)
\n– Scaling is not abstracted (a lot of caching are in the front end code. Its a problem when you start scaling your teams out). They use memcached from what I gather.<\/p>\n

SOA<\/strong>
\n– Data is requested from a service (via HTTP, custom, etc.)
\n– Data requests are run in parallel (over non-blocking sockets. 10 data requests in 1 webpage, and each request takes 10ms. It might now only take 70ms now, maybe, over 100ms. Generally 1.5-2.5x faster now, for blocking parallel requests)
\n– Data requests are asynchronous (non-blocking parallel requests)
\n– Data layer is loosely coupled
\n– Scalability is abstracted (can find engineers anywhere, that can parse JSON or XML :P)<\/p>\n

Options?<\/strong>
\n– Run requests over HTTP (Google (Java), Amazon (Java), etc.)
\n– New York Times’ DBSlayer (small little HTTP server that runs and provides parallel and async requests to mysql)
\n– Danga’s Gearman (binary protocol, has worked, its kind of a queuing system)
\n– Remember the wall clock goes down, but the CPU time is still happening, its still the same<\/p>\n

HTTP w\/PHP<\/strong>
\n1. Group requests for data at the top
\n2. Open a socket for each request
\n– Sockets must be non-blocking
\n– Make sure to use TCP_NODELAY
\n3. Use __get() to block for results
\n4. See Services_Digg_Request<\/p>\n

Use a pear package, called Services_Digg<\/a> for the above example. Note Digg’s API<\/a> documentation as well.<\/p>\n

HTTP is widely supported in all languages. Its very easy to get up and running, with lots of options for servers\/tuning. Overhead in the protocol is great, and Apache itself has a lot of overhead.<\/p>\n

DBSlayer<\/strong>
\n– small HTTP daemon written in C. You post JSON to it for communications
\n– connection pooling (benchmark mysql connection, and there’s a whole bunch of overhead in the mysql authentication; mysql proxy does this too)
\n– load balancing and failover (like mysql proxy)
\n– tightly coupled to MySQL (no migration)
\n– tightly coupled to SQL (no CouchDB)
\n– no intelligence<\/p>\n

Gearman<\/strong>
\n– highly scalable queuing system (worker bees, like PHP scripts. Sockets open, client comes to gearman server to do foo, and it says it has n number of workers, and gearman gets ’em to work. So it works linearly. Jobs can return results back, run in parallel on many gearman servers and many CPUs)
\n– simple and efficient binary protocol
\n– sets of jobs are run in parallel
\n– queue can scale linearly
\n– php, perl, python, ruby, c clients
\n– poorly documented (“I think poorly documented is giving them too much credit.. All danga stuff has next to no documentation”)
\n– livejournal uses this, instead of using HTTP running
\n– its not very “robust” (it scales, they at digg don’t see massive number of failing jobs. Queue isn’t persistent though. When pushing stuff, and gearman gets restarted, the queue goes away – there is a workaround, for this, so ask Joe – its an undocumented feature available though)
\n– digg uses it in the submission process for crawling
\n– Chris at Yahoo! uses Gearman requests to run multiple memcached GETs (if you’re not using multi-get, check them).
\n– Check out Net_Gearman<\/a>, which is a PEAR package<\/p>\n

DIY option?<\/strong>
\n– not recommended, unless you have a highly customised solution, i.e. what Flickr does
\n– they ran into a problem where uploading an image, and then getting the image resized, for large images, was a problem. So they use a custom binary protocol that is much more efficient for the datasets (think, an SLR has files that are 7MB in size or something)
\n– this requires more resources (humans, engineers!)<\/p>\n

What goes in the Services layer?<\/strong>
\n– smart caching strategies
\n– data mapping and distribution
\n– intelligent grouping of data results
\n– partitioning logic<\/p>\n

Remember to intelligently group data into endpoints, and version them! This will help you improve your software.<\/p>\n

Consider bundling and grouping requests (bulk loading).<\/p>\n

EPIC FAIL!<\/strong>
\n– sending SQL over for translation? Pfft. DBSlayer does this, but it tightly couples you
\n– hundreds of teeny tiny endpoints (cohesive endpoints that return a decent amount of data)
\n– running SOA requests sequentially! You then get no benefits from an SOA architecture, at all. Parallel requests are good.<\/p>\n

Technorati Tags: mysql<\/a>, mysqluc08<\/a>, mysqluc2008<\/a>, mysqlconf<\/a>, joe stump<\/a>, digg<\/a>, services oriented architecture<\/a>, soa<\/a>, dbslayer<\/a>, gearman<\/a>, services_digg<\/a>, net_gearman<\/a>, pear<\/a>, sql<\/a>, couchdb<\/a>, flickr<\/a>, amazon<\/a>, scalability<\/a>, performance<\/a><\/p>\n

Share this:<\/h3>