From: Sylvie G. <sgr...@gm...> - 2009-11-29 17:13:48
|
On Sat, 2009-11-28 at 19:26 +0100, Xavier de Pedro wrote: > Hi again with this thread: > > I've been testing tiki performance on a clone of precarios.org with tiki > 2.4 (current version on the server), tiki 3.3 and tiki 4.0 (well, not > the released package but a zipped file from Nov 26th from > dev.tw.o/Download ). > > I recorded the performance of more than 20 actions (recording execution > time, memmory usage, server load, db queries and time) on each tiki > version. Mainly wiki pages, rss for wiki, file upload in file galleries, > and trackers; as anonymous in most cases, and in addition as a user with > admin perms. > > In summary: > > * the file upload interface in file galleries consumed more than 70 Mb > in Tiki 2.4, and 27 Mb in Tiki 3.3 and Tiki 4.0 (congratulations to the > team in Strasbourg for such improvement!) > > * rss for wiki showed blank paage in tiki 2.4, and showed fine in Tiki > 4.0 (forgot in 3.3, sorry). > > * loging in and loading the homepage for registered of precarios.org > took something like 10 seconds using Tiki 2.4, 12 seconds using Tiki > 3.3, BUT **120** seconds using tiki 4.0 (!!!). Some images were missing, > but I wonder if not finding some images referenced by {img src= } could > make the page loda be delayed up to 2 minutes each time! (tried three > times and the same every time). If you are missing images or files. You can not compare the performance > > * trackers have almost the same issues across versions for us. > We have 22 trackers, containing between 1 and 373 items each (1168 items > in total) > I tested 5 of them across the three tiki versions. memory_limit for > php.ini is at the moment at 64 Mb. > The tracker with the worst performance is tracker43, which has: 363 > ítems, 15 fields, shown for admin. Showing 30 items per page. > It's shown in Tiki 2.4, but it isn't in Tiki 3.3 and Tiki 4.0. (memory > exhausted attempting to show the 7th item in the list, out of the 30 > requested). It depends a lot what type of fields your are using . Are you using itm links, itemslist,, etc...? Depends also how it is organized? do you have popup? Are all the fields searcheable.... Sorry I can not understand spanish and navigate on the site...Suppose that one day you will have to send me the database to have a look. > > Another good one is tracker40, with 68 items, 10 fields, which is shown > fine on Tiki 2.4, Tiki 3.3, but It shows just 10 items before the memory > exhausted message in Tiki 4.0. In all cases attempting to display 30 > items per page (as the global setting for the whole Tiki). > When I did set that setting from 30 (items in listings) to 10, it didn't > properly show them yet (memory exhausted again). And when the setting > was lowered to 5 items per page, then tracker40 showed them properly, > with the theme style being loaded and the drop down to filter items by > fields, etc. > > So for trackers, a workaround to avoid the problem of huge memory > consumption even in a tracer with 68 items and 10 fields (over a total > 1168 items in total for all trackers), would be to allow a separate > setting to limit the number of items shown in trackers for all trackers > in Tiki, or in a tracker by tracker level. > > Otherwise, trackers for us are broken with its current design, even in > Tiki 4.0, and even in such a simple tracker with less than 70 items and > 10 fields. > > I hope this can make us more aware of the big performance problems we > have in trackers with this current design, still in Tiki 3.x (LTS) and > Tiki 4.0. > > (I wonder what would have happened with the design in "trackers with > mirror tables", having each tracker on a separate mysql table...). > > Cheers > > Xavi > > > > > En/na Sylvie Greverend ha escrit: > > If somebody wants to backport all the optimizations that have been done > > in 4 (by lph and myself), fine but I will not accept it in proposed. > > Fine in a special branch. Some are very risky. I even think it will bug > > in 4 in the plugins with imbricated fields (like computed and items > > list...) if the fields are not specifically specified. For 4, the fields > > param can be explicitly specified unitl it is fully tested. > > As we say in France : do not put the plow before the oxes > > My 2 cents > > sylvie > > > > > > On Wed, 2009-11-25 at 18:53 +0100, Xavier de Pedro wrote: > > > >> Ok, thanks for the information to all who replied. > >> > >> It seems to me that if we are promoting Tiki 3.x as the Long Term > >> Support (LTS), a backport to 3.x-proposed of such a nice enhancement of > >> trackers made by sylvie in Tiki 4.x (according to the performance > >> improvement reported in this thread), might be awesome! > >> > >> My 2 cents > >> > >> Xavi > >> P.S. I'm willing to pay for precarios.org if needed for such a backport > >> from an experienced coder (I wouldn't want to break the stable branch > >> 3.x myself or make the Quality Team too busy unnecessarily with a bad > >> commit from myself to proposed). Just drop me a message off list if > >> anybody can take care of such backport for some money in exchange. > >> > >> En/na Kerr, Michael E (Mike) ha escrit: > >> > >>> Okie doke, will proceed to upgrade to 4.0 and benchmark. Thanks. > >>> > >>> Mike. > >>> > >>> ______________________________ > >>> Mike Kerr > >>> Sr. Internet Network Engineer > >>> (703) 886-2251 > >>> mik...@ve... > >>> "I didn't come here to be ordinary." > >>> > >>> verizonbusiness > >>> global capability. personal accountability. > >>> http://www.verizonbusiness.com > >>> This e-mail is strictly confidential and intended only for use by the > >>> addressee unless otherwise indicated. > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Michael Risch [mailto:Mic...@ma...] > >>>> Sent: Tuesday, November 24, 2009 6:12 PM > >>>> To: tik...@li... > >>>> Subject: Re: [Tikiwiki-devel] Tracker Performance? > >>>> > >>>> I don't know if Syvlie's changes were backported to 3.3. As I recall, > >>>> > >>>> > >>> the > >>> > >>> > >>>> slowdown was not in the queries (although there was a 4x reduction for > >>>> me), but mostly in the processing of data that wasn't really > >>>> > >>>> > >>> displayed. > >>> > >>> > >>>> The changes now forego processing of data that doesn't need to be > >>>> displayed. Thus, I would say you need to benchmark against 4.x before > >>>> > >>>> > >>> you > >>> > >>> > >>>> make any decisions. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>>> <tik...@li...> 11/24/2009 6:00 PM > >>>>>>> > >>>>>>> > >>>> Date: Tue, 24 Nov 2009 22:55:46 +0000 > >>>> From: "Kerr, Michael E (Mike)" <mik...@ve...> > >>>> Subject: Re: [Tikiwiki-devel] Tracker Performance? > >>>> To: Tikiwiki developers <tik...@li...> > >>>> Message-ID: > >>>> <2C719ECECC2B1049AA6B5143ABF4503E0127D109@ASHEVS004.mcilink.com> > >>>> Content-Type: text/plain; charset="us-ascii" > >>>> > >>>> Here are my preliminary benchmarks at a relative lull in site activity > >>>> at the end of the day: > >>>> > >>>> > >>>> > >>>> 2.2 > >>>> > >>>> Homepage > >>>> > >>>> [ Execution time: 1.40 secs ] [ Memory usage: 12.13MB ] [ > >>>> > >>>> > >>> 203 > >>> > >>> > >>>> database queries used in 0.1 secs ] [ GZIP Disabled ] [ Server > >>>> > >>>> > >>> load: > >>> > >>> > >>>> 0.01 ] > >>>> > >>>> Tracker 26 List > >>>> > >>>> [ Execution time: 8.56 secs ] [ Memory usage: 14.58MB ] [ > >>>> > >>>> > >>> 249 > >>> > >>> > >>>> database queries used in 0.1 secs ] [ GZIP Disabled ] [ Server > >>>> > >>>> > >>> load: > >>> > >>> > >>>> 0.10 ] > >>>> > >>>> > >>>> > >>>> 3.3 > >>>> > >>>> Homepage > >>>> > >>>> [ Execution time: 1.53 secs ] [ Memory usage: 13.39MB ] [ > >>>> > >>>> > >>> 134 > >>> > >>> > >>>> database queries used in 0.0 secs ] [ GZIP Disabled ] [ Server > >>>> > >>>> > >>> load: > >>> > >>> > >>>> 0.05 ] > >>>> > >>>> Tracker 26 List > >>>> > >>>> [ Execution time: 9.59 secs ] [ Memory usage: 15.09MB ] [ > >>>> > >>>> > >>> 167 > >>> > >>> > >>>> database queries used in 0.0 secs ] [ GZIP Disabled ] [ Server > >>>> > >>>> > >>> load: > >>> > >>> > >>>> 0.2 ] > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> This sort of leads me to think that I may have some odd settings I > >>>> > >>>> > >>> need > >>> > >>> > >>>> to resolve somewhere, either in PHP or MySQL... If I run two windows > >>>> side by side and query the 2.2 install on Tracker 26's list in one > >>>> window and 3.3 install on the same list in the other, the 2.2 install > >>>> comes up after about 9 seconds, and I guess since the 2.2 query is > >>>> churning, the 3.3 gets queued up or something because it lasts for > >>>> > >>>> > >>> about > >>> > >>> > >>>> 16 seconds. > >>>> > >>>> > >>>> > >>>> Is there a way to see where the delay is occurring? > >>>> > >>>> > >>>> > >>>> The server I'm on is a VMWare blade with 2G, 80G of HD space, 3.66GHz, > >>>> and all that's running on it is Apache and MySQL. PHP is set for 64M. > >>>> > >>>> > >>>> > >>>> [mysqld] > >>>> > >>>> skip-locking > >>>> > >>>> key_buffer = 256M > >>>> > >>>> max_allowed_packet = 1M > >>>> > >>>> table_cache = 256 > >>>> > >>>> sort_buffer_size = 1M > >>>> > >>>> net_buffer_length = 8K > >>>> > >>>> read_buffer_size = 1M > >>>> > >>>> read_rnd_buffer_size = 4M > >>>> > >>>> myisam_sort_buffer_size = 64M > >>>> > >>>> thread_cache_size = 8 > >>>> > >>>> query_cache_size= 16M > >>>> > >>>> thread_concurrency = 2 > >>>> > >>>> > >>>> > >>>> [mysql] > >>>> > >>>> no-auto-rehash > >>>> > >>>> > >>>> > >>>> [isamchk] > >>>> > >>>> key_buffer = 128M > >>>> > >>>> sort_buffer_size = 128M > >>>> > >>>> read_buffer = 2M > >>>> > >>>> write_buffer = 2M > >>>> > >>>> > >>>> > >>>> [myisamchk] > >>>> > >>>> key_buffer = 128M > >>>> > >>>> sort_buffer_size = 128M > >>>> > >>>> read_buffer = 2M > >>>> > >>>> write_buffer = 2M > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> If this should be moved somewhere else, please let me know. Just > >>>> doesn't make sense to me why performance isn't getting better with > >>>> > >>>> > >>> less > >>> > >>> > >>>> queries, and why concurrent page loads would have such a large > >>>> performance impact. I will point out that the only major difference > >>>> between the 2.2 and 3.3 installs (using the same data) is that 3.3 I > >>>> switched to strasa theme from our custom theme in 2.2. > >>>> > >>>> > >>>> > >>>> > >>>> > >>> ------------------------------------------------------------------------ > >>> -- > >>> > >>> > >>>> ---- > >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > >>>> > >>>> > >>> 30- > >>> > >>> > >>>> Day > >>>> trial. Simplify your report design, integration and deployment - and > >>>> > >>>> > >>> focus > >>> > >>> > >>>> on > >>>> what you do best, core application coding. Discover what's new with > >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july > >>>> _______________________________________________ > >>>> Tikiwiki-devel mailing list > >>>> Tik...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > >>>> > >>>> > >>> ------------------------------------------------------------------------------ > >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > >>> trial. Simplify your report design, integration and deployment - and focus on > >>> what you do best, core application coding. Discover what's new with > >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july > >>> _______________________________________________ > >>> Tikiwiki-devel mailing list > >>> Tik...@li... > >>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > >>> > >>> > >>> > >> ------------------------------------------------------------------------------ > >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > >> trial. Simplify your report design, integration and deployment - and focus on > >> what you do best, core application coding. Discover what's new with > >> Crystal Reports now. http://p.sf.net/sfu/bobj-july > >> _______________________________________________ > >> Tikiwiki-devel mailing list > >> Tik...@li... > >> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > >> > > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > > trial. Simplify your report design, integration and deployment - and focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Tikiwiki-devel mailing list > > Tik...@li... > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |