On Wed, 20 Mar 2019 at 09:43, Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > On Wed, Mar 20, 2019 at 09:17:45AM -0400, Rick Elrod wrote: > > Hi all, > > > > Tahrir is slow, and the endpoint that mediawiki-FedoraBadges uses to get its > > badge count and badge assertion data from takes about 35 seconds per > > request. > > > > As a result, if a user enables both badge count and badge images on a user > > page, the two requests combined take well over a minute. This results in > > mediawiki often bombing the request and rendering an ugly error in place of > > badges. > > > > We get tickets/support requests on this occasionally as well: > > - https://pagure.io/fedora-infrastructure/issue/7650 > > > > Some quick testing shows that the queries I care about for the > > mediawiki-FedoraBadges plugin take about 70ms to run (in prod). Incurring a > > 35 second penalty for that seems *crazy* to me. > > > > As an alternative, I'd like to propose making a tahrir-readonly user, and > > modifying the mediawiki-FedoraBadges plugin to query the badges database > > directly. > > > > I played around and got it working in staging, the process was something > > like: > > > > - Create tahrir-readonly postgres user > > - Grant it readonly perms on the tahrir tables, and connect and usage perms. > > - Modify the mw plugin > > - Install php-pgsql on wiki01.stg so it can actually connect > > > > After that it seems to work fine. I triggered a cache purge of all wiki > > pages on stg as well (but on prod, I'd probably just let the cache naturally > > expire). Pages with badges load almost instantly now (granted the stg data > > is way less than prod, but still). > > > > I'm looking for comments because I don't know if there's anything > > security-wise I'm overlooking in doing this. At a quick glance, it seems > > fine -- the new pg user is readonly and very few people have access to > > LocalSettings.php where the connect info would be stored. But I might well > > be missing something and want to be safe. > > > > Thoughts? > > Sounds fine to me :) > As a ticket been opened upstream so it's not lost that this API needs > optimization? > To this particular one, no. I went and looked at the open issues and saw several 'tahrir is slow' so figured it might be caught up already in those. > Pierre > _______________________________________________ > infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx -- Stephen J Smoogen. _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
