>> Preliminary results with 100 request to the old (non-refactored +
>> prefetch_related) vs 100 requests to the new (this series):
>> Median time for old: 0.226s
>> for new: 0.298s
>> So this appears to be slower. I haven't done any rigorous testing or
>> statistics though.
>> You can do better by changing select_related to prefetch_related. With
>> that, I see a median of 0.197s. I don't think the complexity this
>> patchset brings is justified by a ~30ms/req improvement though.
> Totally agree. Wow, I guess the select_related -> prefetch_related and
> JSON renderer changes made a bigger difference than I could have
> imagined. I'm happy to drop most of this. Nice work!
> The only aspect I would like to keep is a variant of the last two bits.
> From my brief testing, it seems like it's the filtering that's causing
> the huge queries - not the JSON renderer itself. If we can disable this
> from the web UI or, better again, switch to a AJAX-driven system, we'd
> be able to speed up not only '/events' but everything else. Thoughts?
I'm not exactly sure what parts constitute the "last two bits". But, I'm
mostly concerned with changes that touch the database schema, so if it
doesn't do that I'm probably fine. If you can identify the bits you are
talking about I'm happy to review them more closely.
Patchwork mailing list