The potential for HTTP caching will vary greatly across APIs, depending on the usage patterns and how much of the API is public and can be cached in a shared cache. If performance is a serious concern for your API eventually you'll want to stop focusing on optimizing the Web server and instead focus on getting your HTTP caching right. The next step: ETags and network level caching Optimising your database access is by far the most important thing to get right: after that, removing core pieces of the framework provides diminishing performance returns. The sweet spot on the above chart is clearly the third bar from the left. For the cached case you might be looking at closer to a few thousand requests per second. We've not run ApacheBench against these setups, but you might reasonably expect to be able to achieve a rate of a few hundred requests per second on a decent setup. In our basic un-optimized case your application will run pretty much at the same rate as any other simple Django view. The important thing to point out is that the database lookup is the limiting factor. ![]() Views with more complex database lookups, paginated results, or write actions will all have very different characteristics. Remember that these figures are really only intended as a rough insight into these relative timings of the various components. Timing the database lookup and serialization involves modifying the. It's rough and ready (and it goes without saying that you wouldn't use this approach to benchmark a "real" application), but it'll do the job. Rather than use Python's profiling module we're going to keep things simple and wrap the relevant parts of the the code inside timing blocks. In order to time this we can wrap APIView.dispatch in a superclass that forces the response to render before returning it. REST framework's Response object is a type of TemplateResponse, which means that the rendering process takes place after the response has been returned by the view. This includes the mechanics of REST framework's authentication, permissions, throttling, content negotiation and request/response handling. Anything that runs once an APIView has been called. We can time this as everything that takes place in the serializer instantiation and. The time it takes to serialize model instances into simple native python data structure. We can time this by hooking into the request_started and request_finished signals. ![]() This includes the default middleware, the request routing and the other core mechanics that take place on each request. Anything that takes place before or after the view method runs. In order to time this independently of the serialization we'll wrap the queryset call in a list() in order to force it to evaluate. ![]() Here we're timing everything from the Django ORM down to the raw database access. There are various components that we're interested in measuring. Dispelling some mythsīefore we get started, I'd like to first counter some bits of what I believe are misguided advice that we've seen given to developers who are writing Web APIs that need to service thousands of requests per second. Much of this article is Django/Python specific, but the general advice should be applicable to any language or framework. Using a mature, fully featured and well supported API framework gives you a huge number of benefits, and will allow you to concentrate your development on the things that really do matter, rather than expending energy reinventing the wheel. I'm going to be making the case that Web API developers who need to build high performance APIs should be focusing on a few core fundamentals of the architecture, rather than concentrating on the raw performance of the Web framework or API framework they're using. We've seen several cases of developers making these assumptions before they start building their API, and either discounting Django as not being fast enough for their needs, or deciding to not use a Web API framework such as Django REST framework because they 'need something lightweight'. When discussing the scalability of Web services there seems to be a tendency for some developers to overly focus on the framework being used, based on the mistaken assumption that smaller means faster, rather than considering the architecture of the application as a whole.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |