>On Tue, 2008-11-04 at 12:21 -0500, Raymond Dans wrote: >> In debugging XCF-2985(XECS-1854), I noticed that there was a really >> long delay in the sipXsupervisor log between when the >XML/RPC request >> was received (from Config) and when it was actually printed >out (up to >> 2 minutes in some cases). This in turn caused sipXConfig to timeout >> waiting for a response on the success or failure of the replication.
Snip ...... >> >> >> OsSysLog::myvsprintf >> >> - A version of vsprintf that stores the result in a UtlString. >> >> - This method starts by allocating a UtlString of 900 bytes >and tries >> to copy the initial string into it (after parm substitution). If it >> fails because the string is too small, it doubles the size >and tries again. >> This continues until its successful. >> >> - I'd like to modify the allocation of the UtlString to be at least >> the "sizeof" of the format character string passed in if its greater >> than 900 bytes. This will reduce the amount of resizing >that needs to >> occur for strings longer than 900 bytes. Dale wrote: > >It would certainly make sense to start with a size at least >that of the format string, since the output is (almost) >certain to be at least as big. And as you note below, >probably add some padding, although for most messages 10 or 20 >bytes would suffice. > >But I'm wondering why we're seeing this problem -- even in the >bad case of starting with a 900-byte string and doubling it >successively to get a >1.5 Mb string, that's only 11 doublings, which would take >longer than we'd like, but doesn't account for expanding 3 >seconds to 2 minutes. > >More curiously, the code at line 12576 should avoid doubling >when it is run with Glibc 2.1 or later, because vsnprintf >returns the size of the string it needs, so there should be >just one reallocation, and the delay should not be noticable. > >Have you logged the actual pattern of buffer sizes in >myvsprintf? Given what you've seen, I'm sure that there's a >problem here, but the code just shouldn't be showing those symptoms. > I don't think its as much a problem in myvsprintf as it was in the "escape" method. I just looked through this method and noticed that it could be a little smarter. >> >---------------------------------------------------------------------- >> -- >> ---------------------------- >> -Question: Would it be best to actually set the initial capacity to >> the "sizeof" of the format character string + some additional >> buffering since the resulting UtlString will probably be longer. If >> so, then how much extra buffering should I put? >> >---------------------------------------------------------------------- >> -- >> ---------------------------- >> >> >> I have made these changes and tested the replication that >was failing >> before. >> >> My system had 2100 users defined and the delay in processing >> (becausing of the logging) was 2 minutes. With my changes in place, >> the entire sipXsupervisor replication (from reading, logging, >> replicating and returning the result) was about 2 to 3 seconds. The >> size of the XML/RPC request was approximately 1.5 Mb. >> >> I then pumped up the number of users to 3200 and the processing was >> now about 4 seconds. Certainly much better than before. >> >> >> Raymond >> _______________________________________________ >> sipx-dev mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-dev >> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
