tag:blogger.com,1999:blog-54844838479460127022009-08-27T06:36:45.018-07:00Bryan Watershttp://www.blogger.com/profile/08899383838928170725bryanw@abwaters.comBlogger2125tag:blogger.com,1999:blog-5484483847946012702.post-17692454152547057492008-09-21T13:13:00.000-07:002008-09-21T13:20:33.849-07:00The purpose of sharded counters is to reduce contention for a single entity on serialized writes.  The concept is to create multiple sub-counters that are added together to create a single counter with the sub-counter that is incremented selected at random.  This seemed ideal for TCP3 since we need to count pretty much everything.  We count clicks, previews, clicks per day, previews per day, etc. <div><br /></div><div>The problem is that sharded counters take too long.  I'm still profiling, but i'm getting quota warnings on even the memcached sharded counter implementation suggested in one of the Google I/O briefings.  Updating the sharded counters takes 3.5 seconds in my application.  My problem is that i'm not sure if this is a performance problem for appengine or a bug in my code.</div><div><br /></div><div>I'm going to have to consider an alternate implementation.  I'll post details as soon as I come up with something that works.</div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/5484483847946012702-1769245415254705749?l=tcp3com.blogspot.com'/></div>Bryan Watershttp://www.blogger.com/profile/08899383838928170725bryanw@abwaters.com0tag:blogger.com,1999:blog-5484483847946012702.post-77819429388425525662008-09-10T19:09:00.001-07:002008-09-10T19:17:43.196-07:00Any application that needs to scale needs to designed to do so from the beginning.  Or at least that's what I used to think.  Even when Amazon introduced EC2 and S3 there were still design requirements that you needed to consider.  In fact, I actually started this project with S3 as the back-end.  The idea was to store the URLs on S3 which had very quick response times and use quick scalable hosting (I hadn't decided which hosting service at that time) with round-robin DNS to scale the front-end.  It was a simple architecture but it would have worked.  But...before I was able to go very far with the project, Google launched AppEngine.  AppEngine took an entirely different approach to scalability.  Use their SDK and platform and don't even bother with scalability.   So, I decided to switch over and give it a try.<div><br /></div><div>This project is the ongoing development effort based on that decision.   I will describe and write about design decisions, feature plans and problems and roadblocks caused by the AppEngine platform.</div><div><br /></div><div>Oh, and feel free to comment.  I will approve any and all constructive comments both postitive and negative.<span class="Apple-tab-span" style="white-space:pre"> </span></div><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/5484483847946012702-7781942938842552566?l=tcp3com.blogspot.com'/></div>Bryan Watershttp://www.blogger.com/profile/08899383838928170725bryanw@abwaters.com0