Boost bug sprint?
Since we're now at November 13th, and I originally proposed starting the bug sprint "after the 1.45" release, and "On November 15th", I think that something's gotta give. So, I'm proposing that we start the bug sprint on Saturday, November 27th, and run through Sunday, December 5th (9 days, two weekends, one work week). That way people who work on boost as part of their day jobs will have a full week to participate, while those who do "nights and weekends" will have plenty of time as well. What does everyone think? -- Marshall
On Sun, Nov 14, 2010 at 9:38 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Since we're now at November 13th, and I originally proposed starting the bug sprint "after the 1.45" release, and "On November 15th", I think that something's gotta give.
So, I'm proposing that we start the bug sprint on Saturday, November 27th, and run through Sunday, December 5th (9 days, two weekends, one work week). That way people who work on boost as part of their day jobs will have a full week to participate, while those who do "nights and weekends" will have plenty of time as well.
What does everyone think?
I like the timing. I will participate in the bug sprint too so count me in. Thanks Marshall! -- Dean Michael Berris deanberris.com
On 1:59 PM, Dean Michael Berris wrote:
On Sun, Nov 14, 2010 at 9:38 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
Since we're now at November 13th, and I originally proposed starting the bug sprint "after the 1.45" release, and "On November 15th", I think that something's gotta give.
So, I'm proposing that we start the bug sprint on Saturday, November 27th, and run through Sunday, December 5th (9 days, two weekends, one work week). That way people who work on boost as part of their day jobs will have a full week to participate, while those who do "nights and weekends" will have plenty of time as well.
What does everyone think?
I'd love for a bug-sprint priority to be fixing the Trac system. That would be a huge boon for ongoing bug-fixing (i.e., the Guild). Pretty specialized, I know. What's it take to make that happen?
On 11/17/2010 8:47 AM, Jim Bell wrote:
On 1:59 PM, Dean Michael Berris wrote:
On Sun, Nov 14, 2010 at 9:38 AM, Marshall Clow<mclow.lists@gmail.com> wrote:
Since we're now at November 13th, and I originally proposed starting the bug sprint "after the 1.45" release, and "On November 15th", I think that something's gotta give.
So, I'm proposing that we start the bug sprint on Saturday, November 27th, and run through Sunday, December 5th (9 days, two weekends, one work week). That way people who work on boost as part of their day jobs will have a full week to participate, while those who do "nights and weekends" will have plenty of time as well.
What does everyone think?
I'd love for a bug-sprint priority to be fixing the Trac system. That would be a huge boon for ongoing bug-fixing (i.e., the Guild).
Pretty specialized, I know.
What's it take to make that happen?
Depends.. What do you think is wrong with Trac? Have you noticed any difference this week compared to last week? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Nov 17, 2010, at 8:50 AM, Rene Rivera wrote:
On 11/17/2010 8:47 AM, Jim Bell wrote:
On 1:59 PM, Dean Michael Berris wrote:
On Sun, Nov 14, 2010 at 9:38 AM, Marshall Clow<mclow.lists@gmail.com> wrote:
Since we're now at November 13th, and I originally proposed starting the bug sprint "after the 1.45" release, and "On November 15th", I think that something's gotta give.
So, I'm proposing that we start the bug sprint on Saturday, November 27th, and run through Sunday, December 5th (9 days, two weekends, one work week). That way people who work on boost as part of their day jobs will have a full week to participate, while those who do "nights and weekends" will have plenty of time as well.
What does everyone think?
I'd love for a bug-sprint priority to be fixing the Trac system. That would be a huge boon for ongoing bug-fixing (i.e., the Guild).
Pretty specialized, I know.
What's it take to make that happen?
Depends.. What do you think is wrong with Trac? Have you noticed any difference this week compared to last week?
Took the words right out of my mouth. My major complaint is with the speed. It seems like every time I bring up the Trac web page, the load average on the server is 3 or 4 or 7. But I'm guessing that that is not what Jim wants to change. -- Marshall
On 1:59 PM, Rene Rivera wrote:
On 11/17/2010 8:47 AM, Jim Bell wrote:
I'd love for a bug-sprint priority to be fixing the Trac system. That would be a huge boon for ongoing bug-fixing (i.e., the Guild).
Pretty specialized, I know.
What's it take to make that happen?
Depends.. What do you think is wrong with Trac? Have you noticed any difference this week compared to last week?
Performance: way too slow. But now it's making a liar out of me--seems to be responding well. Did someone work on it?
On 11/17/2010 11:46 AM, Jim Bell wrote:
On 1:59 PM, Rene Rivera wrote:
On 11/17/2010 8:47 AM, Jim Bell wrote:
I'd love for a bug-sprint priority to be fixing the Trac system. That would be a huge boon for ongoing bug-fixing (i.e., the Guild).
Pretty specialized, I know.
What's it take to make that happen?
Depends.. What do you think is wrong with Trac? Have you noticed any difference this week compared to last week?
Performance: way too slow.
But now it's making a liar out of me--seems to be responding well. Did someone work on it?
It was kinda a loaded question on my part :-) But I didn't want to bias your response by telling you ahead of time that I did work on it over the weekend & Monday. And did some minor changes that sped things up somewhat. Still looking for other things to do. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 1:59 PM, Rene Rivera wrote:
On 11/17/2010 11:46 AM, Jim Bell wrote:
On 1:59 PM, Rene Rivera wrote:
On 11/17/2010 8:47 AM, Jim Bell wrote:
I'd love for a bug-sprint priority to be fixing the Trac system. That would be a huge boon for ongoing bug-fixing (i.e., the Guild).
Pretty specialized, I know.
What's it take to make that happen?
Depends.. What do you think is wrong with Trac? Have you noticed any difference this week compared to last week?
Performance: way too slow.
But now it's making a liar out of me--seems to be responding well. Did someone work on it?
It was kinda a loaded question on my part :-) But I didn't want to bias your response by telling you ahead of time that I did work on it over the weekend & Monday. And did some minor changes that sped things up somewhat. Still looking for other things to do.
I still see load averages in the 12-16 range, which seems high. Is that a concern? Seems like it's caching or something: response times seem pretty uneven. (Aren't I the typical user? Even if it did my laundry and read my mind, I'd still stay, "yeah, but look at what it's still not doing!") But it does seem significantly better! Thanks!
On 11/17/2010 3:58 PM, Jim Bell wrote:
On 1:59 PM, Rene Rivera wrote:
It was kinda a loaded question on my part :-) But I didn't want to bias your response by telling you ahead of time that I did work on it over the weekend & Monday. And did some minor changes that sped things up somewhat. Still looking for other things to do.
I still see load averages in the 12-16 range, which seems high. Is that a concern?
Seems like it's caching or something: response times seem pretty uneven. (Aren't I the typical user? Even if it did my laundry and read my mind, I'd still stay, "yeah, but look at what it's still not doing!")
But it does seem significantly better! Thanks!
Having just executed a couple of queries and modified some trac tickets, I can say that trac is still really slow. One of the queries even timed out waiting for svn.boost.org to respond. I'd say there's still a problem. Rene, anything you could do would be hugely appreciated. I'm talking BIG karma in the afterlife. :-) -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Nov 17, 2010, at 2:53 PM, Eric Niebler wrote:
On 11/17/2010 3:58 PM, Jim Bell wrote:
On 1:59 PM, Rene Rivera wrote:
It was kinda a loaded question on my part :-) But I didn't want to bias your response by telling you ahead of time that I did work on it over the weekend & Monday. And did some minor changes that sped things up somewhat. Still looking for other things to do.
I still see load averages in the 12-16 range, which seems high. Is that a concern?
Seems like it's caching or something: response times seem pretty uneven. (Aren't I the typical user? Even if it did my laundry and read my mind, I'd still stay, "yeah, but look at what it's still not doing!")
But it does seem significantly better! Thanks!
Having just executed a couple of queries and modified some trac tickets, I can say that trac is still really slow. One of the queries even timed out waiting for svn.boost.org to respond. I'd say there's still a problem. Rene, anything you could do would be hugely appreciated. I'm talking BIG karma in the afterlife. :-)
What's the hardware underneath svn.boost.org? What else is that hardware doing? Can we upgrade the hw or move stuff off that box? -- Marshall
On 18/11/2010 0:00, Marshall Clow wrote:
On Nov 17, 2010, at 2:53 PM, Eric Niebler wrote:
Having just executed a couple of queries and modified some trac tickets, I can say that trac is still really slow. One of the queries even timed out waiting for svn.boost.org to respond. I'd say there's still a problem. Rene, anything you could do would be hugely appreciated. I'm talking BIG karma in the afterlife. :-)
What's the hardware underneath svn.boost.org? What else is that hardware doing? Can we upgrade the hw or move stuff off that box?
Without knowing the exact setup, I don't believe that there is a load or hardware problem, because in my experience trac (in general) is slow. We have a recent server (with gbit ethernet, too) which does nothing but svn + trac for 3-8 users, which is as slow as boosts trac. HTH Fabio
Hi List, I cannot confirm the thoughts of Fabio, we have an Trac version internaly which just runs fine. It is not as slow as that Trac installation of Boost is. I guess that is maybe something with Webserver/Python installation or an Plugin problem?! -- On Thu, Nov 18, 2010 at 11:26 AM, Fabio Fracassi <f.fracassi@gmx.net> wrote:
On 18/11/2010 0:00, Marshall Clow wrote:
On Nov 17, 2010, at 2:53 PM, Eric Niebler wrote:
Having just executed a couple of queries and modified some trac tickets, I can say that trac is still really slow. One of the queries even timed out waiting for svn.boost.org to respond. I'd say there's still a problem. Rene, anything you could do would be hugely appreciated. I'm talking BIG karma in the afterlife. :-)
What's the hardware underneath svn.boost.org? What else is that hardware doing? Can we upgrade the hw or move stuff off that box?
Without knowing the exact setup, I don't believe that there is a load or hardware problem, because in my experience trac (in general) is slow. We have a recent server (with gbit ethernet, too) which does nothing but svn + trac for 3-8 users, which is as slow as boosts trac.
HTH
Fabio
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Mit freundlichen Grüßen, With best regards, Wolfgang Forstmeier Homines sumus nun dei (Petronius) ------------------------------------------- mailto:wolfgang.forstmeier@gmail.com
On 11/18/2010 6:28 AM, Wolfgang Forstmeier wrote:
Hi List,
I cannot confirm the thoughts of Fabio, we have an Trac version internaly which just runs fine. It is not as slow as that Trac installation of Boost is.
I guess that is maybe something with Webserver/Python installation or an Plugin problem?!
Sure.. Do you have any suggestions as to what the problem is? We don't have that many plugins installed: The base Trac plugins, IniAdmin, SpamFilter, and XMLRPC (unused for now I think). Python is 2.6.something running with WSGI (I don't think mod_python is an option for the OSL admins). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Fri, Nov 19, 2010 at 12:50 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
On 11/18/2010 6:28 AM, Wolfgang Forstmeier wrote:
Hi List,
I cannot confirm the thoughts of Fabio, we have an Trac version internaly which just runs fine. It is not as slow as that Trac installation of Boost is.
I guess that is maybe something with Webserver/Python installation or an Plugin problem?!
Sure.. Do you have any suggestions as to what the problem is?
(Apologies for jumping in) Not really a suggestion, but a question: have we configured Trac to use an RDBMS backing store, or are we still using SQLite to handle the massive number of tickets we have on there?
We don't have that many plugins installed: The base Trac plugins, IniAdmin, SpamFilter, and XMLRPC (unused for now I think). Python is 2.6.something running with WSGI (I don't think mod_python is an option for the OSL admins).
I think we're running into IO issues with SQLite being the main source of contention. I cannot confirm this remotely though, but I do think it may be worth looking into moving the tickets out of a SQLite store into a MySQL server -- so that at least we're able to tune the MySQL configuration independent of Trac. Usually, high system loads mean that there are a lot of active processes on average on the system. This can mean that the subversion processes spawned along with the Trac usage (maybe someone's spidering Trac, like Google/Microsoft) through the web is causing the high system loads. If CPU utilization is not that high I'm willing to bet that we're running into the IO bounds of the server svn.boost.org is hosted on. Just a guess though, I can help with some investigation when I get some free time. HTH -- Dean Michael Berris deanberris.com
On 11/18/2010 11:02 AM, Dean Michael Berris wrote:
On Fri, Nov 19, 2010 at 12:50 AM, Rene Rivera<grafikrobot@gmail.com> wrote:
On 11/18/2010 6:28 AM, Wolfgang Forstmeier wrote:
Hi List,
I cannot confirm the thoughts of Fabio, we have an Trac version internaly which just runs fine. It is not as slow as that Trac installation of Boost is.
I guess that is maybe something with Webserver/Python installation or an Plugin problem?!
Sure.. Do you have any suggestions as to what the problem is?
(Apologies for jumping in)
Not really a suggestion, but a question: have we configured Trac to use an RDBMS backing store, or are we still using SQLite to handle the massive number of tickets we have on there?
AFAICT we are still using sqlite for the Trac DB.
We don't have that many plugins installed: The base Trac plugins, IniAdmin, SpamFilter, and XMLRPC (unused for now I think). Python is 2.6.something running with WSGI (I don't think mod_python is an option for the OSL admins).
I think we're running into IO issues with SQLite being the main source of contention. I cannot confirm this remotely though, but I do think it may be worth looking into moving the tickets out of a SQLite store into a MySQL server -- so that at least we're able to tune the MySQL configuration independent of Trac.
Perhaps, but that's a more drastic change :-) But I'll look at what's involved in migrating to MySQL.
Usually, high system loads mean that there are a lot of active processes on average on the system. This can mean that the subversion processes spawned along with the Trac usage (maybe someone's spidering Trac, like Google/Microsoft) through the web is causing the high system loads.
Most of Trac and all of SVN are excluded from spidering. The only part that's indexed is the wiki, AFAIK.
If CPU utilization is not that high I'm willing to bet that we're running into the IO bounds of the server svn.boost.org is hosted on.
Unfortunately.. The CPUs are pegged most of the time. The top 8 or so processes are always httpd and are pegged at a 400% CPU usage. So it points less at IO contention and more are an intensive/inefficient process.
Just a guess though, I can help with some investigation when I get some free time.
Help is appreciated. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 11/17/2010 5:00 PM, Marshall Clow wrote:
What's the hardware underneath svn.boost.org?
It's a 4-way SMP Intel Xeon 2.8GHz machine with 4Gig RAM.
What else is that hardware doing?
Mailman only AFAICT.
Can we upgrade the hw or move stuff off that box?
Only if someone else volunteers the resources.. I.e. hardware, bandwidth, and administration. But to me it seems like the hardware should be sufficient to run Trac, SVN, Mailman, and more. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Nov 18, 2010, at 9:15 AM, Rene Rivera wrote:
On 11/17/2010 5:00 PM, Marshall Clow wrote:
What's the hardware underneath svn.boost.org?
It's a 4-way SMP Intel Xeon 2.8GHz machine with 4Gig RAM.
What else is that hardware doing?
Mailman only AFAICT.
Can we upgrade the hw or move stuff off that box?
Only if someone else volunteers the resources.. I.e. hardware, bandwidth, and administration. But to me it seems like the hardware should be sufficient to run Trac, SVN, Mailman, and more.
That certainly sounds like the hardware should be sufficient for what it's doing. [ Thanks for answering my query! ] However, I loaded up the main page this morning, and saw: • Server Load Average: 8.54 That seems really, really, high to me. -- Marshall
On 11/18/2010 11:48 AM, Marshall Clow wrote:
On Nov 18, 2010, at 9:15 AM, Rene Rivera wrote:
On 11/17/2010 5:00 PM, Marshall Clow wrote:
What's the hardware underneath svn.boost.org?
It's a 4-way SMP Intel Xeon 2.8GHz machine with 4Gig RAM.
What else is that hardware doing?
Mailman only AFAICT.
Can we upgrade the hw or move stuff off that box?
Only if someone else volunteers the resources.. I.e. hardware, bandwidth, and administration. But to me it seems like the hardware should be sufficient to run Trac, SVN, Mailman, and more.
That certainly sounds like the hardware should be sufficient for what it's doing. [ Thanks for answering my query! ]
However, I loaded up the main page this morning, and saw: • Server Load Average: 8.54
That seems really, really, high to me.
And that's not a usually high number ;-) The load tends to go from 6 to 16 on this machine. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Hi, does anyone know, why boost::this_thread::get_id() is about 60 times slower than PR_GetCurrentThread(). boost version : 1.42 platform and os : 32bit, win xp sp3 compiler : msvc8 lib : boost_thread-vc80-mt-p-1_42.dll measured : 10 million executions of PR_GetCurrentThread and boost::this_thread::get_id(), where the latter took 1.5s and the previous only 75ms. Both measures with high performance counter from outside the loop and assignment to vector, to avoid optimizations by compiler. What makes this so ridiculous, is that boost::thread_specific_ptr performans quite well, as fast like PR_GetCurrentThread. Do I ignore some implementation or optimization intrinsics ? Greetz, Ingo.
On Wed, Nov 17, 2010 at 6:00 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
What's the hardware underneath svn.boost.org? What else is that hardware doing? Can we upgrade the hw or move stuff off that box?
IIRC it's a pretty beefy (if not cutting-edge) Mac Pro, and it's basically just serving Boost Trac, Website, SVN, and mailing lists... but DongInn should be able to cast an accurate light on it. Frankly, I think Trac is stagnating as a project, and even if we speed it up somehow we will find other reasons to switch away from it eventually. Redmine is always a likely candidate at times like these, but I'm especially attracted to the idea of letting someone like GitHub host our issue tracking, since their bottom line will depend on maintaining its speed and usability. However, we'd want to complete modularization before making a change like that. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote:
On Wed, Nov 17, 2010 at 6:00 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
What's the hardware underneath svn.boost.org? What else is that hardware doing? Can we upgrade the hw or move stuff off that box?
IIRC it's a pretty beefy (if not cutting-edge) Mac Pro, and it's basically just serving Boost Trac, Website, SVN, and mailing lists... but DongInn should be able to cast an accurate light on it.
Frankly, I think Trac is stagnating as a project, and even if we speed it up somehow we will find other reasons to switch away from it eventually. Redmine is always a likely candidate at times like these, but I'm especially attracted to the idea of letting someone like GitHub host our issue tracking, since their bottom line will depend on maintaining its speed and usability. However, we'd want to complete modularization before making a change like that.
I should say that I've been extremely happy with the functionality of the Trac system. I can't speak to any other issues with (it does seem slow at times). I just would hate so see any of the functionality I use - issue tracking posting of patches, svn browsing, etc lost in any improvements. Robert Ramey
At Thu, 18 Nov 2010 12:24:31 -0800, Robert Ramey wrote:
I should say that I've been extremely happy with the functionality of the Trac system. I can't speak to any other issues with (it does seem slow at times). I just would hate so see any of the functionality I use - issue tracking posting of patches, svn browsing, etc lost in any improvements.
Definitely not. Except for the SVN part of "svn browsing" ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
If you really cannot fix that behaviour of trac being slow we really should think about something different because in my eyes there is nothing worse than a project with an incredible slow website. If we think about moving to something else take a look at JIRA (http://www.atlassian.com/software/jira/) which is in my opinion a really good bunch of software. But moving is always a big thing. Please try first to find out what is going on on that web server we currently use. I really cannot belief that Trac is this slow. -- On Thu, Nov 18, 2010 at 9:40 PM, David Abrahams <dave@boostpro.com> wrote:
At Thu, 18 Nov 2010 12:24:31 -0800, Robert Ramey wrote:
I should say that I've been extremely happy with the functionality of the Trac system. I can't speak to any other issues with (it does seem slow at times). I just would hate so see any of the functionality I use - issue tracking posting of patches, svn browsing, etc lost in any improvements.
Definitely not.
Except for the SVN part of "svn browsing" ;-)
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Mit freundlichen Grüßen, With best regards, Wolfgang Forstmeier Homines sumus nun dei (Petronius) ------------------------------------------- mailto:wolfgang.forstmeier@gmail.com
On 11/17/2010 4:53 PM, Eric Niebler wrote:
On 11/17/2010 3:58 PM, Jim Bell wrote:
On 1:59 PM, Rene Rivera wrote:
It was kinda a loaded question on my part :-) But I didn't want to bias your response by telling you ahead of time that I did work on it over the weekend& Monday. And did some minor changes that sped things up somewhat. Still looking for other things to do.
I still see load averages in the 12-16 range, which seems high. Is that a concern?
Seems like it's caching or something: response times seem pretty uneven. (Aren't I the typical user? Even if it did my laundry and read my mind, I'd still stay, "yeah, but look at what it's still not doing!")
But it does seem significantly better! Thanks!
Having just executed a couple of queries and modified some trac tickets, I can say that trac is still really slow.
Right.. Some things are much faster, because of caching and low server needs like most of the wiki content. But other are still slow, but faster than they where before, like complicated queries..
One of the queries even timed out waiting for svn.boost.org to respond.
Which one specifically? I could use it as a test case to measure improvements and investigate why it's slow.
I'd say there's still a problem. Rene, anything you could do would be hugely appreciated. I'm talking BIG karma in the afterlife. :-)
I'd prefer BIG karma in my current life though ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 11/18/2010 12:06 PM, Rene Rivera wrote:
On 11/17/2010 4:53 PM, Eric Niebler wrote:
One of the queries even timed out waiting for svn.boost.org to respond.
Which one specifically? I could use it as a test case to measure improvements and investigate why it's slow.
The 1.45 showstoppers query.
I'd say there's still a problem. Rene, anything you could do would be hugely appreciated. I'm talking BIG karma in the afterlife. :-)
I'd prefer BIG karma in my current life though ;-)
:-) BTW, I recall someone (Daniel James?) saying that the slow website performance has to do with the constant zipping/unzipping of ... something. Docs? I can't remember. Could that be related? -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 11/18/2010 11:20 AM, Eric Niebler wrote:
On 11/18/2010 12:06 PM, Rene Rivera wrote:
On 11/17/2010 4:53 PM, Eric Niebler wrote:
One of the queries even timed out waiting for svn.boost.org to respond.
Which one specifically? I could use it as a test case to measure improvements and investigate why it's slow.
The 1.45 showstoppers query.
On the first try that has a response of 6s plus 1s for the HTML, and 1s more for the images, CSS and JS. Total at 9.07s. Which is not bad. On the second try, with a few more things now cached, it takes me 5.06s. And after a few tries, the lowest it goes is 2.59s. Which is rather good. Of course if there was some results on the page it would take longer :-) For example report #1 on first try (most things still cached) takes me 8.16s. Which is good IMO since it's returning 100 tickets.
I'd say there's still a problem. Rene, anything you could do would be hugely appreciated. I'm talking BIG karma in the afterlife. :-)
I'd prefer BIG karma in my current life though ;-)
:-)
BTW, I recall someone (Daniel James?) saying that the slow website performance has to do with the constant zipping/unzipping of ... something. Docs? I can't remember. Could that be related?
I spent this past weekend investigating that after it was brought up again by the admins. And the result from analyzing the performance data is that there is no unzipping problem, as far as the test results go. WE no longer serve docs from ZIPs. One of the fixes I did Monday was to remove the gzip content compression on Trac pages. That had the effect of reducing server load enough to speed response times significantly. The other change was to fix some bad cache items so that they would actually get client cached. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
----- Original Message ----- From: "Marshall Clow" <mclow.lists@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, November 14, 2010 2:38 AM Subject: [boost] Boost bug sprint?
Since we're now at November 13th, and I originally proposed starting the bug sprint "after the 1.45" release, and "On November 15th", I think that something's gotta give.
So, I'm proposing that we start the bug sprint on Saturday, November 27th, and run through Sunday, December 5th (9 days, two weekends, one work week). That way people who work on boost as part of their day jobs will have a full week to participate, while those who do "nights and weekends" will have plenty of time as well.
What does everyone think?
It's Ok. Best, Vicente
participants (12)
-
Dave Abrahams -
David Abrahams
-
Dean Michael Berris -
Eric Niebler -
Fabio Fracassi -
Ingo Loehken -
Jim Bell -
Marshall Clow -
Rene Rivera -
Robert Ramey -
vicente.botet -
Wolfgang Forstmeier