Re: patchwork.ozlabs.org down, and e-mails not recorded

> "daggs" == daggs writes: Hi, > happened to me too (not rejection), I've sent 4 patches in hope that > they will be reviewed on the hackathon but I don't see them in > patchwork. I guess you are referring to these patches?

Re: patchwork.ozlabs.org down, and e-mails not recorded

Hi Jeremy, > Hi Daniel, > >> We have quite a few of these sitting in our queue :-( > > After a bit of time with some extra debug enabled for the buildroot mail > feed, I see this for the failed parsemail invocations where we've > returned a temp-fail: > > No handlers could be found for logger

[PATCH 2/2] api: EventList: Only provide JSON version

Something is very, very slow in the d-r-f browsable API events renderer. In my MySQL test (~33k patches), the CPU time to render the events list is ~11s, and the time taken by SQL queries is only ~3s. If the JSON renderer is used, that drops to 0.2s for the entire page (because less CPU is used,

[PATCH 1/2] api: EventList: change select_related() to prefetch_related()

select_related() creates a single giant query that JOINs the required tables together in the DB. prefetch_related() does a similar thing, but at the Django layer - for all referenced models, it makes a separate query to the DB to fetch them. This massively, massively simplifies the job the DB has

[PATCH 0/2] Fix slow EventList API endpoint

Hi, In the process of reviewing Stephen's series, I had an independent look at what was making the event list api endpont so slow. My analysis is that the DB queries can be improved, but that the main slow-down is due to some weirdness in how d-r-f's browsable API renderer works. Stephen, this

Re: [RFC 1/4] Automatically remove old events

Daniel Axtens writes: > Stephen Finucane writes: > >> On Thu, 2018-01-25 at 16:21 +1100, Daniel Axtens wrote: >>> Hi Stephen, >>> >>> This is a good idea and I'm happy for it to go in as-is, before the >>> rest >>> of the series. >>> >>> Reviewed-by: Daniel