Uploaded image for project: 'FishEye'
  1. FishEye
  2. FE-227

Internally parallelize p4 print output

    XMLWordPrintable

Details

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

    Description

      Right now, indexing a particular p4 repository appears (from looking at the process tree of a running FishEye instance) to be a serialized sequence of "p4 print" statements. However, "p4 print" is a latency and not bandwidth sensitive operation, and it almost always makes sense to perform these with some degree of parallelism. But it's necessary for FishEye to index a p4d running over a high-latency WAN.

      One way to see precisely how bad things can be is to try to index a Perforce repository on a proxy on a WAN (London-->Hong Kong) link, where the proxy isn't hot:

      FishEye --> Local p4p --> Remote p4d

      If the p4p is cold, it looks like what's happening is that FishEye is running a bunch of "p4 print" operations in series, each of which is quite synchronous and thus latency sensitive (in our case we have more than enough bandwidth to spare). So while you get some minor speedup on a local server at the expense of thrashing your FishEye and P4 installations, you would get MASSIVE performance benefits out of parallelizing the "p4 print" operations to some extent.

      This was originally raised as a comment on FE-122 due to a misunderstanding of what that issue really meant.

      Attachments

        Activity

          People

            Unassigned Unassigned
            aca233f59075 Kirk Wylie
            Votes:
            4 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated: