Stories
Slash Boxes
Comments

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Wednesday October 31, 2007
06:23 AM

A grant for rt.cpan.org hardware?

[ #34801 ]

I have no idea why rt.cpan.org remains such an utterly slow-almost-to-the-point-of-no-longer-being-useful website, but something really needs to be done about it.

I can't help but wonder if the Perl Grants Committee would buy Jesse a dedicated machine to run it on (I hear it's tacked onto the side of a server with a number of other things, but I could be wrong).

Do people think this would be a worth use of the community's money?


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

A grant for rt.cpan.org hardware? 24 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I certainly like the idea. Many people have been frustrated by the slowness of CPAN's RT. I don't know if the grant committee will approve it since we don't have a proposal, but it's worth a shot.

    • For such a small organization with so little work to do, it seems that waiting for a proposal is just needless process. You can make any rules that you like, and you can awards grants how you like. Be proactive rather than reactive.

      Really, shouldn't TPF be out there looking for things to improve rather than waiting for someone to make a grant proposal (which apparently are often summarily rejected just on format)? If you really want to be helping the community, you make it as easy as possible for the commun

      • For such a small organization with so little work to do...

        Allison does very little handling our legal issues. The new artistic license just wrote itself. Jim Brandt finds running the conference committee a breeze. Ask and Robert are just laughing out how little work it takes to maintain all of our servers. Andy just waves his hand and press releases get written for him. I found running the grant committee so relaxing and stress free that I finally stepped down. Kirsten just looks at our Web sites and the pages write and redesign themselves. I'm sure Kurt

        • Ah, bullshit Ovid. Whine whine whine. TPF isn't an organization with volunteers all doing part-time stuff. It isn't a big foundation with millions of dollars in a full time staff responding to thousands of grant applications. You talk about a lot of things that happened in the past by people who don't need to be parts of the grant process. Why are you using that as an excuse about why the grant process can't be different?

          I could volunteer for all sorts of things, but why should I? I don't need TPF to accomp
          • That is, TPF is an organization with volunteers all doing part-time stuff

          • I don't whine about how much work it is unless someone tells me that it's not. And I don't understand why you're getting hostile. I apologize if my tone was offensive. I meant it to be tongue-in-cheek, but clearly it didn't come across that way.

  • I would *also* like the ability to pick a different bug tracking system to display information on search.cpan, but rt.cpan.org is intolerably slow. Faster would be much, much better -- and possibly a second grant for other improvements.
    --
    rjbs
    • FWIW, I've been in the process of moving my queues for {Test::,}WWW::Mechanize over to Google Code because of the slow. Also, because I like Google Code's bug tracking facilities more than RT.
      --

      --
      xoa

      • Yeah, I saw your recent post to module-authors (?). I don't mind RT per se, but rt.cpan.org's slowness, plus some other issues*, make it a big pain.

        * Some examples
        1. can't easily get a listing of all bugs for all my queues
        2. can't shut off wildly-spammy email interface
        3. logins are way, way too short-lived (compounds slowness)
        4. public/private URL for bug makes redirection after login hateful

        I'd love to see these fixed. I once offered to sponsor having them fixed, but the answer I got was something like, "No one shou

        --
        rjbs
  • I'd vote for such a grant, should somebody apply for one.

    Additionally, YAPC::Europe 2007 left Vienna.pm with quite a lot of money, which will go back to various Perlish things. We're currently working on the details, but the Perl community can expect some cash in the near future - and putting some of it into a faster rt.cpan.org would be a good idea!
  • So, the last time someone complained about rt.cpan.org's performance, I dropped in some new logging. And actually caught a bogus query that had some Serious performance implications. A quick index fixed it right up. And we've been watching the logs since then. Of the last 25,000 page loads, 95+% have rendered fully to the browser in under two seconds. What I need to know (and a journal post isn't the right place for this. mail to jesse@bestpractical.com would be much better) is 1) What was slow. What page

    • Here's what I am seeing right now. Loading page http://rt.cpan.org/Public/ [cpan.org] took 3.584 seconds according to FasterFox, but the in page time reads 'Time to display: 0.181015'. My ping time to rt.cpan.org is about 90 ms.

      My search for bugs on Apache::Dispatch http://rt.cpan.org/Public/Dist/Display.html?Name=Apache%3A%3ADispatch [cpan.org] took 7.67 seconds according to fasterfox, and page time reads 'Time to display: 5.985952'. My search for bugs on mechanize http://rt.cpan.org/Public/Dist/Display.html?Name=WWW%3A%3AMe [cpan.org]

    • One example for me...

      Resolving a bug, with comment.

      Time to load, around 20+ seconds.

      Time page says it took, 3.5 seconds.
      • Adam,

        You're a developer. You _know_ how to report bugs. (You also have tools like YSlow and Firebug which can give you real numbers)

        But

        1) what IP are you coming from
        2) What URL were you starting from.
        3) What URL did you end up at?
        4) how long did one of the aforementioned tools tell you it took?
        5) What _exact_ time did it happen at?

        What you gave me is basically no better than "it's slow. and lied to me." - Which isn't much to work with.
        • I was in a hurry :)

          Point me at the RT queue for rt.cpan.org and I'll file it properly.
          • The cpan-questions address on the front page of the site will log it in the right place.

            I have a minion with a whole slew of tasks related to fixing up the source for publication and fixing a couple of the worst _known_ performance issues over the next couple weeks. When we do that, we'll be able to cpan rt.cpan and move bug tracking to rt.cpan. ;)
            • I've been sending stuff to that address, and apart from a short period after the most recent upgrade, they fall into the bit bucket and I never know what state they are in after an initial "thanks for the message" response.

              Is the queue actually visible somewhere?

              • FYI, I'm following along and if it turns out that hardware is part of the problem, TPF will do what we can to fix things. As it is, it appears Jesse is on the case and has a few things to try before we buy new hardware.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.