Hi, Thanks,
I know that I haven't given any other specifics, the reason for this is that it wasn't specific and it's hard to describe. I have described as much as possible currently. Regarding downgrading - we have tried that on everything - we have reverted migrations, downgraded code and versions of libraries - everything. Unfortunately we haven't been able to rule out any culprit. The reason I asked my first question was to hear if anyone else has experienced this - and if they have found any reason for it. Apparently this is not the case - so we will continue searching. But thanks for the suggestions regardless :-) Regards, Andréas Den lör 28 dec. 2019 kl 12:53 skrev Integr@te System < [email protected]>: > Hi Andreas, > > # First at all we couldn't help anymore without specified problem as your > necessary show no more clear details. > > # Tools(for profiling each running functions, many metrics need), advices > from some other to help you see out of box and show them out to our > supports. > > # Plan to upgrade, include procedure, backward version recover from > unexpected result. Libraries, dependency and so on. > > Example: DRF drop python2, paging, Q object, _url... many so on. > So I wonder your hidden work or just want to survey on community for using > these software packages. > Thank for sharing. > > > On Sat, Dec 28, 2019, 02:33 Andréas Kühne <[email protected]> > wrote: > >> Ok - let's take this one piece at a time. >> >> 1. As far as we have been able to tell is that we have nested serializers >> for certain aspects of the application - those went from loading in 3-4 s >> to over 40 s in different places. It's hard to exactly show, however the >> number of database requests skyrocketed as well. But our theory is >> currently that the related models (foreign keys) are loaded strangely. >> 2. We aren't exactly sure WHERE the bottlenecks are happening - that is >> also why the question is wide and generic. >> 3. We don't have any profiling tools running in production, however the >> figures we do have are on development. >> 4. We upgraded from the latest version of 2.2 to 3.0 in django and >> upgraded one minor version of DRF at the same time. >> >> The main issue is that we got performance issues - major performance >> issues - while upgrading. This shouldn't be possible - not in the way that >> it happened. What worries us is if this happens again and we don't see this >> BEFORE a production release. That was the main problem we had. >> >> We have now done a lot of workarounds in place where the code was slow - >> but we would still like to understand where the problems occur so that we >> don't get this surprise again. >> >> My question was more generic - because we wanted to see if anyone else >> had experienced the same problems when upgrading. >> >> The strangest thing now is that even if we downgrade the database >> (reverse migrations), downgrade the code and so on - the requests are still >> slow - where they haven't been previously. >> >> Regards, >> >> Andréas >> >> >> Den fre 27 dec. 2019 kl 10:33 skrev 'Amitesh Sahay' via Django users < >> [email protected]>: >> >>> Also let us know the procedure that you adopted to upgrade to the new >>> version? >>> >>> Regards, >>> Amitesh >>> >>> >>> On Thursday, 26 December, 2019, 10:19:31 pm IST, Jason < >>> [email protected]> wrote: >>> >>> >>> Also, you haven't stated where the bottlenecks are happening. Is it app >>> code, internal in django, your stack, database, networking? There's alot >>> of variables in play for diagnosing a major slowdown, and you've provided >>> no information about profiling/monitoring >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> >>> https://groups.google.com/d/msgid/django-users/37b9526a-756f-4ac7-835a-af49f0dada02%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-users/37b9526a-756f-4ac7-835a-af49f0dada02%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-users/2119895222.3536368.1577439175073%40mail.yahoo.com >>> <https://groups.google.com/d/msgid/django-users/2119895222.3536368.1577439175073%40mail.yahoo.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/CAK4qSCeUAhcoqGFesXTHvWyNGfE1-HEHASwPB8Lq-PPDhh_6%3Dw%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-users/CAK4qSCeUAhcoqGFesXTHvWyNGfE1-HEHASwPB8Lq-PPDhh_6%3Dw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CAP5HUWomX%2BVN6hbrnEuW29GtaWZg_gXYdNnLAacQOoHLgM_C4A%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CAP5HUWomX%2BVN6hbrnEuW29GtaWZg_gXYdNnLAacQOoHLgM_C4A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAK4qSCcfqh0GwYDVtg8qqzyszL2g%2BJ%2BnCtw_fUCXARo6hnOrMQ%40mail.gmail.com.
