On 03/ 9/10 05:03 PM, Evan Layton wrote: > On 3/9/10 4:15 AM, Jan Damborsky wrote: >> Hi Evan, >> >> are those problems specific to AI configuration >> (e.g. network configuration, memory consumption) ? > > The problems specific to 13066 appear to be mostly network related > which is not necessarily an AI issue.
I think the point is that we don't really know. > However what I'm really asking > for here is if we think there may be things in addition to the network > problems described in bug that may also be contributing to the overall > performance problems. > One example might be things like grouping some > of the package installs together to reduce the number of pkg install > commands. Also things like looking into using the pkg api directly to > help speed things up. I don't know if any of these ideas even > reasonable or make any sense but I wanted to at least get some > discussions going on these types of things. If I understand correctly, there are several potential problems being reported and evaluated: [1] scalability problem on pkg consumer side (reported in comment #25 in bug 13321) [2] scalability problem on pkg server side (original report in bug 13321, bug 13267) [3] networking issue (bug 13066) As you pointed out above, we know what the problem is in #1- there is a scalability regression in pkg CLI which slows down installations in AI and DC (as Keith reported in comment #30 for bug 13321), since transfer module calls 'pkg install' for each package. We know it will be addressed by transfer module effort Jean is working on. With respect to #2 and #3, those were seen with AI, but I think it might be useful to try DC in the same environment to determine how AI contributes to those issues. Also, if the problem is reproducible with DC, I think it might make further evaluation and debugging easier. Jan
