On Tue, 2008-11-04 at 12:21 -0500, Raymond Dans wrote: > I'd like to propose modifying the identified methods (escape and > myvsprintf) to be a little smarter in how its allocating the > UtlString(s) to avoid the resizing as much as possible. This will not > only resolve the replication issue but will probably make the logging a > lot more efficient. > > OsSysLog::escape > > - accepts a UtlString as source and returns an escaped version of the > source in another UtlString. > > - I'd like to modify the result (return) string so that its > size/capacity is set to be at least the size of the source UltString. > This will drastically reduce the amount of resizing that needs to occur. > > > ------------------------------------------------------------------------ > ----------------------------- > -Question: Would it be best to actually set the initial capacity to the > size of the source + some additional buffering since the escaped version > will actually be a longer. If so, then how much extra buffering should > I put?
You could just do something simple like add 100 bytes. You could also do something clever like measure the real escaping. The syslogviewer undoes the escaping, so take some real large log files and measure the distribution of line lengths; then run those files through syslogviewer and measure them again. Comparing the two distributions may suggest a good buffer to add. > 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. > > ------------------------------------------------------------------------ > ---------------------------- > -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. Did you retain the old versions? If there are no other users of the old versions (or it's easy to convert any other uses), I'd say just remove them in favor of your new ones. > 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. Great job 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
