On Mon, 2010-02-22 at 10:57 -0500, Huijun Yang wrote: > > > Unless we have a good reason, let's disable it. We don't even cache > hibernate queries right now, and AFAIK, that improve performance a lot > more > than this. > > As we have added quite a few of rest services, and more will come for > sure in the future... Any performance at a particular point might not be > significant, but will adds up. In my opinion, the approach 2 does not > seems to be difficult to implement, and it does not bring new side > effect, why we want to throw away the benefits of cache if we don't have > to?
One of the most important things to remember about optimizing for performance is the "90/10" rule - 90% of your time is spent in 10% of your code. Optimizing the wrong 10% of your code buys you exactly _nothing_, except possibly increased code complexity. I have not seen many complaints about sipXconfig performance - the only one I have personally is that the phonebook is too slow to be usable, and I bet that's not a user cache problem. Possibly there are problems with the performance of replicating some configuration data sets, and I'm sure those are not user cache issues. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
