On Fri, Jun 1, 2012 at 6:57 PM, Tim Chase <django.us...@tim.thechases.com>wrote:
> On 06/01/12 03:56, Subhranath Chunder wrote: > > With that in mind, how should we measure response complexity? > > Any particular parameter, scale? Probably I can measure against > > that, and share the numbers to shed more light on how many > > requests can be handled in with a particular hardware config. > > There are a pretty small number of bottlenecks: > > 1) computation (a CPU-bound problem) > 1b) algorithm (usually manifests as a CPU problem) > Not much computation involved in my case as far as I see. At most cases it's all about zero or one db hit. memcache used to keep the data already prepared. Still nothing like being able to measure the computation. How would you measure it? > 2) I/O > 2a) disk > 2b) network > 2c) memory > Don't think these might be creating much bottleneck in my scenario. But still, nothing like getting to exact figures. Again, how would you measure it? > > Most of them can be mitigated through an improvement in algorithm or > by adding an appropriate caching layer. There's also perceived > performance, so spawning off asynchronous tasks (such as via celery) > can give the user the feel of "I've accepted your request and I'm > letting you know it will take a little while to complete". > > In any testing that I do, I try to determine where the bottleneck > is, and if that can be improved: Did I choose a bad algorithm? Am > I making thousands of queries (and waiting for them to round-trip to > the database) when a handful would suffice? Am I transmitting data > that I don't need to or that I could have stashed in a cache > somewhere? Am I limited by the CPU/pipe/disks on my machine? > The focus of the application has been to reduce bottlenecks as much as possible. Zero or one query, extensive use of memcache, async tasks(via celery), etc. it's all there in application layer to reduce the bottlenecks. > > There's no single number to measure the complexity, but often > there's an overriding factor that can be found addressed, at which > point another issue may surface. > Are we sure. The round-trip response time for a request to the server, can't that be used as a single number to measure the complexity? (Given the fact that the server is deployed in Amazon EC2 Singapore location, as m1.xlarge with all it's network, memory constrains in place) > > -tkc > > > > -- Thanks, Subhranath Chunder. www.subhranath.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
