Great reply Joe, keep pushing forward.
Announcement
Collapse
No announcement yet.
Questions I would like to see Joe respond to:
Collapse
X
-
Originally posted by Ramsesx View Post
Great reply Joe, keep pushing forward.Last edited by Loco.M; Sat 26th Dec '09, 5:59pm.
-
Originally posted by Ramsesx View PostYes, you're right, there are no problems on a dead testforum with cms disabled and don't doing anything on it.Originally posted by Loco.M View PostI've installed it on multiple active forums as well and it's running for fine..Thx!
Great reply Joe, keep pushing forward.
Comment
-
Originally posted by centris View PostLooks like he does not want to share guys, what does that tell you?
Comment
-
Originally posted by Mark.B View PostIt tells me he's not working at the moment because it's Christmas.ManagerJosh, Owner of 4 XenForo Licenses, 1 vBulletin Legacy License, 1 Internet Brands Suite License
Director, WorldSims.org | Gaming Hosting Administrator, SimGames.net, Urban Online Entertainment
Comment
-
Originally posted by Nick View PostPerhaps the high query count isn't something we should be worried about as much as we think...
vBulletin 4 Coding Quality
http://www.adminaddict.net/forum/vbu...ex4/#post57050
Recent discoveries (on my part) have quite possibly negated my defense of the queries issue, simply because it happens on every page rather than it simply being a "cold cache" as I explained on your site.
This is a problem. The 100 to 200 queries wouldn't be an issue if it was what I explained, but it isn't.
Unfortunately, I haven't even bought the CMS yet, I'm just explaining what I know as a PHP Developer. So I can't confirm or deny my conclusions.
Comment
-
CMS does 52 queries for my home page.
Page generated in 0.0932879447937 seconds with 52 queries, spending 0.0103414058685 doing MySQL queries and 0.0829465389252 doing PHP things.
This is a typical query. Note the elapsed time.
Code:SELECT template FROM vb_template WHERE templateid = 5228Time Before: 0.09243 seconds Time After: 0.09247 seconds Time Taken: 0.00004 seconds
Code:SELECT parent.category AS parentcat, cat.categoryid, cat.category, info.title, cat.catleft, cat.catright, info.title AS node, childnode.nodeid, count(nodecat.nodeid) as qty FROM vb_cms_node AS node INNER JOIN vb_cms_node AS childnode ON childnode.nodeleft BETWEEN node.nodeleft AND node.noderight INNER JOIN vb_cms_nodeinfo AS info ON info.nodeid = childnode.nodeid INNER JOIN vb_cms_category AS parent on parent.parentnode = childnode.nodeid INNER JOIN vb_cms_category AS cat ON cat.catleft BETWEEN parent.catleft AND parent.catright LEFT JOIN vb_cms_nodecategory AS nodecat ON nodecat.categoryid = cat.categoryid WHERE node.nodeid = 1 GROUP BY parent.category, cat.categoryid, cat.category, cat.catleft, cat.catright, info.title, childnode.nodeid, info.title ORDER BY childnode.nodeleft, catleft;Time Before: 0.05448 seconds Time After: 0.05454 seconds Time Taken: 0.00006 seconds
Comment
-
Originally posted by Super Jinni View PostThe question is:
What is vB going to do about it?
The amount of queries is just not right. It should be dropped to near 30 or so.
Originally posted by Joe Rosenblum View PostGood questions, thanks. As I mentioned before, 4.0 is a new release and has some of the short-comings of a new release while still also having overwhelming value (in my opinion). I'll try to answer the specific questions above as best as possible:
- A lot of folks have mentioned the high query count on CMS; I think 'query count' is a misleading metric. The real question is: how long does it take to render the page? We've made a number of fundamental changes to the DB schema in 4.0 that improve performance in a variety of areas, and some of the improvements have changed the way we approach some parts of the application design. In the case of CMS we would rather have a lot of tiny queries that take a few milliseconds each than a few large joins that take hundreds of milliseconds. Our product offers an incredibly rich set of features including our incredibly fine grained permissions, and we don't want to compromise the offering; that said, we can absolutely do better on CMS performance and we will be working on improving this in the future.
- Regarding personalization/custom profiles: look for this in one of the upcoming point releases.
- As far as the QA process and high bug count: our QA process has been improving constantly throughout the last phase of the development cycle. We think we've delivered a better product, faster than anytime in the history of vBulletin and we will continue to drive new feature development while maintaining high quality. We have recently hired more QA and engineering staff to help out. For more detail on the process we have used and are using, please see my previous article.
I hope that helps give some insight into where we are at. I'm very proud of the great work the team has done on 4.0 and I know that there is a lot more to come.
Comment
- A lot of folks have mentioned the high query count on CMS; I think 'query count' is a misleading metric. The real question is: how long does it take to render the page? We've made a number of fundamental changes to the DB schema in 4.0 that improve performance in a variety of areas, and some of the improvements have changed the way we approach some parts of the application design. In the case of CMS we would rather have a lot of tiny queries that take a few milliseconds each than a few large joins that take hundreds of milliseconds. Our product offers an incredibly rich set of features including our incredibly fine grained permissions, and we don't want to compromise the offering; that said, we can absolutely do better on CMS performance and we will be working on improving this in the future.
-
I am still longing to see a list of mid sized and larger upgrades with the CMS that didn't require new hardware. The only people I am seeing content with the resource usage are hobby sites with minimal activity.
I understand the need to defend ones work and stoically beam with pride to 'rally the troops', however IMO Joe's post is a larger problem then the query count. There is no acceptance of any issues (apart from the throw away comment about 'short-comings'), no acknowledgement of customer frustrations and no apparent drive to do something about it (because apparently there just isn't a problem). Just a bunch of 'emperor has no clothes'. This is why vB is in the state it is in. It really gets my goat as well as I (like many) were really sold on the whole "investing more than ever before, more developers than ever, qualified QA process, strong management team, yadayadayada". I feel like I have a lot vested in vB4 and at the same time feel totally used.
In case you hadn't noticed, my vB love meter just slipped another notch.
Comment
-
Originally posted by Joe Rosenblum View PostGood questions, thanks.
Originally posted by Joe Rosenblum View Post4.0 is a new release and has some of the short-comings of a new release while still also having overwhelming value (in my opinion).
Originally posted by Joe Rosenblum View PostI'll try to answer the specific questions above as best as possible:
- A lot of folks have mentioned the high query count on CMS; I think 'query count' is a misleading metric. The real question is: how long does it take to render the page? We've made a number of fundamental changes to the DB schema in 4.0 that improve performance in a variety of areas, and some of the improvements have changed the way we approach some parts of the application design. In the case of CMS we would rather have a lot of tiny queries that take a few milliseconds each than a few large joins that take hundreds of milliseconds. Our product offers an incredibly rich set of features including our incredibly fine grained permissions, and we don't want to compromise the offering; that said, we can absolutely do better on CMS performance and we will be working on improving this in the future.
- Regarding personalization/custom profiles: look for this in one of the upcoming point releases.
- As far as the QA process and high bug count: our QA process has been improving constantly throughout the last phase of the development cycle. We think we've delivered a better product, faster than anytime in the history of vBulletin and we will continue to drive new feature development while maintaining high quality. We have recently hired more QA and engineering staff to help out. For more detail on the process we have used and are using, please see my previous article.
- I'll reserve further comment on the queries as others have discussed it in length here.
- This is sad. It's a missing feature that many communities utilize. It took years to get it. Now it's gone and we don't have a solid answer as to when it will be back. Just in one of the upcoming point releases. That could mean weeks or months. Not only is this missing, but customizing the blogs is missing too.
- Good to hear.
- I can't help but feel we went backwards when you look at 3.8 compared to 4.0 from an end users perspective. 3.8 has more end user features than 4.0 now. My major concern is how the end users will see this. You take away custom profiles and blogs...and give them what? End user friendliness and personalization is the most important for any social site. If you look in the suggestion forums you will see many requests geared toward just that.
Originally posted by Joe Rosenblum View PostI hope that helps give some insight into where we are at. I'm very proud of the great work the team has done on 4.0 and I know that there is a lot more to come.
The team, I commend. My concerns are directed at where VB is heading and where we are today with it.
There's no doubt that a roadmap outlining what IB's plans are for vb in the future, would certainly help. Not just "there's great things to come...let's jump for joy", but "here is a list of what is to come in their estimated time frames". And some security in knowing that end users usability will be thought of first and refactored from where we are now.Last edited by CallieJo; Tue 29th Dec '09, 12:05pm.
Comment
widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
Comment