First let me say that I love D5, developed a lot of sites with it, its fast reliable and works great. D6 is almost great with an exception of admin pages. There are certain admin pages that right out of the box require 1000+ queries to display a single freaking page. A fresh clean install of D6 with no modules installed other than devel will generate 1054 sql queries just in displaying the module list page. D5 out of the box generates only 43. The bad news is this is worse case scenario. Add content to your site and the number of queries grow. I have over 40,000 nodes and the module list page requires 5000+ queries just to load the modules page coupled with about 6000 queries if I hit the save button. Want to carry out a DOS attack on your own database? Use D6 in a production environment with hundreds of users requesting pages then try and look at the modules page. If you have 40,000 nodes like myself you will find yourself killing apache, mysql and restarting them. Views are another no no, saving a view requires around 3000 queries to save. Want to clear the cache? Clearing the cache costs me 5600+ sql queries!
I assumed that the core code for D6 was tested and ready for production after waiting nearly a year to finally use it. I am very skeptical when it comes to using third party modules due to not knowing if the developers know what they are doing. It would appear that the core code can no longer be trusted. Who profiled these pages and thought it was a good idea to launch production code that would require literally thousand upon thousands of queries just to load certain pages with the number of queries multiplying as content is added?
I will say that coupled with APC and aggressive caching my site runs incredibly quick for my users. The problem is I can't install modules, I can't create views, I can't update views, I can't clear the cache without completely crashing my site. I now have to resort to bringing the site offline late at night when traffic is low and then making my updates on a slow, slow, slow application due to the ungodly amount of queries.
With that being said if you are a core drupal developer and you are developing pages that right out of the box with zero content require 1000+ sql queries to display a single page you really need to rethink your development practices...you made a wrong turn somewhere.
Some of you will probably assume that this rant is the result of something not being configured properly etc... Nope, it has been a known issue for months now that has yet to be fixed. You can follow the frustration that other developers like myself are experiencing at these links:
http://drupal.org/node/304505
http://drupal.org/node/302638
http://drupal.org/node/311626
I can't help but think that issues like this are a result of the Drupal community feeling they have to pop out new versions of drupal every 9 months. my 2 cents.
Comments
=-=
views I tend to build on a development site export the code and turn it into a custom.module
clearing cache I tend to do right from phpmyadmin and not from the admin UI.
I also tend to put a site in maintenance mode and clear my sessions table after doing all I can to inform the users. ie: newsletter, site announcement.
What I do aside, yes it is a reported problem but what the above post fails to disclose is the issue is being actively worked on see: http://drupal.org/node/302638
While the work is being done on Drupal 7.x which was originally Drupal 6.x the changes will be backported once a final patch is RTBC.
Thanks for the input I will
Thanks for the input I will definitely start using some of these practices and appreciate the advice.
I do realize that these issues are being addressed and my post links to threads indicating they are being addressed. I in no way meant to imply they weren't. What is troubling is that these issues weren't caught before release and it has been over a year since the launch of D6 and they still haven't been fixed.
I would assume that the development team takes efficiency into consideration when coding, I would expect that they would know the estimated amount of queries required to process certain requests. Releasing a version that requires 1054 database calls just to show the list of modules installed is insane. It really tests my confidence in what the drupal community is putting out. This indicates to me that the code isn't being thoroughly tested and attention to detail is lacking in an attempt to release the next version rather than creating the best CMS possible.
_
There is no core development team-- drupal is us-- all of us. It's also a scratch your own itch type community. If this is such a troubling issue for you I'm sure any one of the threads mentioned, and perhaps others, would be grateful for any assistance on pushing them forward.
I'm not trying to be cynical, and your post is thoughtful and well formed, but i can't help but wonder if that time could have been better spent contributing to a solution. In any case, anyone already working on the issue(s) is, more than likely, not going to see this post.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
There is no troubling issue
There is no troubling issue with the fact that drupal is open source, I would imagine that this is the reason that most of us are attracted to it coupled with the fact that it is one of the best CMS around. The idea that there aren't core developers whose opinions weigh more than others due to their experience and intimate knowledge of drupal is a little far fetched. In fact you can find a list of the core developers here http://drupal.org/node/21778 I would expect that if novice developers contribute code that uses bad design principals it would get caught by one of these developers and would not be committed to an official release. There is a review process. Drupal didn't get where it is today by allowing people to commit code to the core at will. That is my point, the fact that code was committed allowing a page to make 5000+ DB calls, possibly more depending on quantity of content, when all the page does is show a list of activated and deactivated modules is a huge mess up. That does reflect the lack of detail required to compete in a very competitive market where there are a lot of just as free alternatives that function really well. The fact that there are several pages that seem to suffer from this problem right out of the box mind you is fairly disturbing.
I am not trying to ruffle feathers, I love Drupal, I want to see it continue to excel but it is things like this that will allow competitors to gain ground and possibly surpass Drupal. Yes I realize that I could be working on a solution right now to fix these things, but that isn't the point. The point is there are a lot of us who believe that thoroughly tested and well thought out development should have higher precedence than trying to force new versions of drupal out the door as quickly as possible.
_
I never said there wasn't. Once you've participated and the relative merits of your work are familiar, there's less reason to be critical. My point was that anyone can rise to that level-- all it takes is work. It's not a closed group as in many other open source projects.
Again, I never said there wasn't. What i said was that there isn't an 'official core development team', and there isn't. period. Anyone can submit patches to core-- even i have had a tiny patch committed to core. In the same way, the review process also includes anyone in the community that wants to participate (see the patch spotlight). Drupal actively encourages participation by everyone and anyone.
Ultimately, the final authority on what gets committed to core is Dries. There is also one additional designated branch maintainer per major version that has core commit rights as well (that's what the page you link to above is describing). But it's the entire community that creates the patches that get reviewed and considered. What's far fetched is the idea that a project as complex and fast moving as drupal could be the result of only a handful of people, lol.
No, it doesn't. The issue was vetted-- and it was determined to have that page function that way on purpose. The technical reasons why are beyond my skills to completely understand, but it most definitely was consciously addressed. It's not fair to confuse your opinion of whether or not that decision was valid by claiming there couldn't have been a process used to arrive at it. There's an issue floating around for it, if I find it, I'll post it. There's also a couple of issues trying to optimize it.
I'm not trying to ruffle feathers either, honest-- i love the open collaboration and back and forth nature of open source. Particularly with drupal. But the misconception that there is some cabal of drupal developers that decide this or that is a common one and I try to clear it up whenever encounter it. you really can participate on issues that are important to you. No your first patch won't receive the amount of respect and attention as well known high profile contributors, but neither did the first patches of those high profile contributors. Webchick, the 2nd core maintainer of d7, started out a couple years ago as a google summer of code student-- everyone has to start somewhere.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
Look, I am not trying to be
Look, I am not trying to be Mr. KnowItAll but I have been developing web apps for over 10 years using many different open source projects as well as contributing to various open source projects. You don't have to give me a primer on the process involved, I am familiar with it. Contrary to what you assume, I don't believe that there is nazi dictator at the top of Drupal dictating every byte that is allowed into the project.
Whether these new pages were intended to work this way or it is a result of something being overlooked it doesn't matter. Intending to create pages that literally make exponential calls to the database is INSANE planned, vetted, or not. In fact I would feel a little better knowing that it was something that slipped through the cracks and wasn't actually planned to function in this manner. If you don't see the logical issues in pages that make thousand and thousands and thousands of DB calls to display a single page then you and I really don't have anything to discuss.
=-=
Not for nothing but, when you recite your resume it makes others (me in this case) wonder why with the skillset you must have acquired over the last 10 years? why not help solve the problem? get in an get your hands dirty instead of just seemingly flinging mud.
It takes those with the knowledge to roll up their sleeves and get involved in the process. I freely admit that I can't help in this case as I don't have the skillset that's been built over a decade.
Yet another thread about an issue you already know is being worked on doesn't seem to me to help solve the problem at all. It just starts another debate which isn't all that constructive really.
_
I wasn't addressing the technical aspect of the function of this particular page, I was addressing your misconceptions of how the drupal community works. Regardless of your resume or experience with open source sw development, your view of how the drupal community works was incorrect and all I was trying to do was point in you in the right direction so you don't waste your time.
The simple fact is, like it not, your well constructed and thoughtful post in this forum is a complete waste of time. I was simply trying to clarify the best way forward on an issue that appears important to you.
We do agree on one thing-- there really is nothing more for us to discuss.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz