I have a more-or-less ignored site that I am intending to spend some time on in the coming year. The URL is http://www.Spain-Info.com.
Plans include extending the area guides to provide at least a stub on every city, village and dusty roadside crossroads in Spain (well, almost), to put in a links directory keyed to the topical areas of the site, and to add a lot of fresh content.
In some ways, Drupal obviously would be great. I'm guessing that someone who knows what they are doing could move the site to a couple of templates that would have to look better than the current site, with the CSS helping with the search engines. The forums are quite inactive, and even if they pick up a lot, the Drupal forum module would be more than up to the task. The capability for registered users to submit comments and articles is also a huge draw, as the site could work better in a lot of ways with some community.
Here's the question - if I do move it over, and expand the area guide to include hundreds of locales in Spain, add a directory with several thousand entries (which it would have if it just picked up the DMOZ listings) and expanded the other content with a couple of hundred extra pages, I am looking at a taxonomy tree with thousands of twigs on it.
Some of the posts on the forums made me think that when things get this complicated, Drupal gets slow and burdens the server. That would be a problem, because this site, and most of my other sites, are running on an anemic pentium server that does fine with the mainly static HTML I put on it now but which might drop to its knees if stressed unduly. I could, in theory, upgrade to a better server or servers, but I'm kind of cheap and the site does not make that much money, so I would prefer not to be pushed into buying a lot of shiny new hardware if other solutions would run with less overhead.
In other words, the posts made it seem like maybe Drupal works well for a site with a pretty contained taxonomy scheme (such as your typical blog), but gets stressed when you get thousands of pages involved.
Site traffic is moderate, about 200,000 pages a month or less, and even with the changes and some promotion I would not expect it to go anywhere near a million pages a month anytime soon, so the site should be able to keep running where it is unless the sheer size of the taxonomy creates problems.
Can anyone guide me on this? Technically, I am a naif, with very limited chops, so I might have just misunderstood what I read here and elsewhere.
Comments
Very interesting subject
I am giving this a bump as I am interested in some answers too.
The other thing that I found a little cumbersome with large taxonomy trees is the drop down menu for "create content" which grows disproportinately. I would prefer several levels of drop down menus:
instead of
cat1
-subcat1
--subsubcat1
--subsubcat2
-subcat2
--subsubcat3
cat2
-subcat3
--subsubcat4
I would like to see:
menu1: menu2: menu3
cat1 subcat1 subsubcat1
cat2 subcat2 subsubcat2
menu2 menu3 change depending on what is selected in the previous menus (show only relevant subcats).
In the example above cat1 and subcat1 are selected.
Anyways, I can see my drop down menu explode.
Andre
Dropdowns will be a killer
Good point.
There's not much to be done about a much bigger database requiring much bigger storage. I believe it will scale geometrically, and that's at good as you can hope for.
If you plug in the devel.module you can see how much time the requests are taking, but I think taxonomy will expand OK - unlike menu whcih would (possibly) cause a severe hit in performance as every item is loaded into memeory all the time.
But anyway - the drop-downs will be simply painful. (I think they are already on a medium-sized site)
The alternatives are a pop-up 'browse' menu done either on the server or as DHTML on the client, or some magic with sub-select boxes.
It could be done on the client, or possibly using Ajax.
I don't know if anyone has thought of addressing this task yet.
I think we also need this widget so we can select nodes from a form meaningfully.
.dan.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
devel module
Where can I find it? I have been looking in my installation:
admin/modules
and here:
http://drupal.org/project/Modules
I would like to give it a shot to help me debug some other problems.
Re: Devel.module tips and installation
I've found devel.module in the CVS, together with a short readme file.
You will also want to look at the list of issues before installing it. It's more updated then the documentation. There are around 10 issues opened for this module - read them carefully and select the correct version for your installation. The last working revision for Drupal 4.6 is the one prior to the Forms API update that has recently landed (rev 1.55). So I downloaded version 1.55 and got an error that the timer_read function is missing. So I used the patch in http://drupal.org/node/24904 to add this function conditionally if needed. It is needed if you are using a version later then 1.50. I applied the patch to version 1.55 and it works great with drupal 4.6.x.
Module features:
* Displays the page execution time.
* Displays the list of SQL queries used to generate the page.
* Display page redirects.
* Output is only visible to authorized used.
Amnon
-
Personal: Bring Dolphin's Simple Joy to your Work - Job - Career
Professional: Small Business Web Host
Hm
Nevermind I found 1.55 thanks for your reply.
I got a question though:
ms # query
What does the # column stand for? I have a couple of them at 2 and they are red. Does this mean this query got executed twice? If so why?
Andre
no big deal
It's red becaused yes, the same query was run twice.
There are many reasons why this could happen, none of them compleeing.
While most modules attempt to cache DB lookups themselves, sometimes doing so seems trivial.
If two different modules both wanted to find out the same info, and both chose to use direct DB access to do so, there's nothing much to prevent two independant queries both being made at different times.
Slightly inefficiant, but nothing to worry about if the queries are simple.
If you were to display similar information both in a side block and (say) in the footer of a page, but wanted to turn either feature on and off, lightweight coding would just ask for the same info in each place.
Heavyweight coding would abstract that lookup into a either a static routine, or possibly store the info in the node itself. Either option would bulk the code out a bit, and may not have been considered by the author.
I've seen a lot of double-ups coming from the image module. Not sure why.
Depends totally on what the query is to see what the problem is.
I patched devel (or was it database.inc) to give me a third column with a mini stack-trace next to each query summary to see where it was actually being called from.
.dan.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
So Drupal Is Not a Good Choice?
I'm trying not to be a total idiot, but I think what I am hearing here is that Drupal is not such a good choice for a site with a big taxonomy menu, if only because the drop down menus are going to be a huge drag on performance.
Did I get that right?
Ray Campbell
skype raywcampbell
Well..the dropdowns are not
Well..
the dropdowns are not a performance hit - no more than any other page that wanted to list a few hundred options in one menu.
They are just annoying widgets for maintainence. Won't make a diff to the user/browser or server.
.dan.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Can anyone help
As it stands, I don't think I have gotten a responsive answer to my question. Is Drupal a bad idea for a site with a large taxonomy tree?
I am not in a position to build a Drupal site and test it to see if Drupal would be a good idea for this application. I am figuring that there has to be someone here who could give me a bit of guidance.
Big taxonomy
I don't know that much, but I have developed a site with a relatively large taxonomy: various departments have their own taxonomy, events have their own set of terms, articles have the same, etc.
I will say, that from an end users perspective, the taxonomy access module seems to be essential so that my users only see the terms in the dropdown list that apply to their content. This way they don't have to sift through a massive list everytime they create a page.
I'm not sure that helps, but the taxonomy I've developed seems to work so far...
if you want to have a very
if you want to have a very large taxonomy tree you need the hardware to execute the queries associated with that. i have no idea if your old Pentium is up to that. It also depends on whether your site has mainly anonymous visitors or also authenticated ones. For anon visitors Drupal's cache works very efficiently, but for logged in visitors there is no cache.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Thanks
I appreciate your taking the time to respond. I guess the ultimate answer from the experts here is that there is no way to make a reasonable prediction about whether Drupal would slow down my particular site on my particular server until after I convert and build out the site.
The visitors now are all anonymous, because it is a HTML site. No telling what they would be on Drupal, but since it is an information site rather than a community site, I'm guessing most of them would still be anonymous. I don't know, of course, and to the extent I have relevant information on the scope of the site and the power of the server, it is posted above. If that's not enough to make a reasonable prediction on, then it's just one of those things that is inherently uncertain, I suppose.
I'm thinking that I will just keep the site on HTML for the time being. It's easy enough to manage what I have now in Dreamweaver, and I get the feeling that Drupal is not an appropriate choice for someone with my low level of technical skills. It feels like a program where there is help if you start with a pretty high level of technical chops, if not in Drupal then in all the relevant LAMP technologies, but not like one where someone starting from a zero base line can comfortably move up the curve within the community. I don't have much of reliable value to contribute to a community this technically oriented (I could talk all day on internet marketing or legal issues, but there is no place for that in this particular community, perhaps because that stuff is not needed by the people here), and I am not way comfortable seeking help without putting something reliable and of value back in.
Anonymous
If your users are anonymous now, they will be anonymous in Drupal.
On my photosite:
http://www.aguntherphotography.com
I do not provide a login either.
The thing that tipped me over the edge to using Drupal was maintanance. I had close to 2000 html files. Even though Dreamweaver can update them all at once, you still have to upload them all to the server. It was more or less a loose collection of html files.
I have been very happy with the migration so far. Maybe you can think of a way to reduce the size of the taxonomy tree.
I am using the taxonomy menu module on another site. By default the taxonomy tree is collapsed, with a little + sign next to each item, that lets the user expand this. I don't think there is a limitation on the amount of items you can have, just try to keep your menus small. This will also make your site more userfriendly.
The thing I noticed on my photosite is the extremely large amount of database requests per displayed site. This is a problem on my shared host (not yet but if traffic keeps growing at the current rate).
This is mainly due to the Acidfree module. Even after patching it and reducing the number of pagers, I still get over 200 DB requests when a search is performed (I belive Acidfree pulls everything from the database for each of the results displayed - 10 per page). This is prob. unnessesary and could be reduced.
You may have to do some small mods, but I think your pentium should be fine. I am running two sites on a shared hosting account. So far no trouble.
The only problem I am having with the number of request is the limit set by the host. The requests are small and should be executed fairly fast.
I am by no means an expert, but if you help me with "internet marketing" I can help you with the implementation ;-)
(Next year that is).
I think marketing and legal skills are very valuable although widely neglected.
Andre
Internet Marketing, Law, Etc.
I am certainly willing to pontificate at the drop of a hat on internet marketing, selling online advertising, raising investment money, selling sites, and the few other things I have actual experience in, whether or not you have time to help on the technical implementation of any site of mine. Ditto on the law, but I have to caveat that while I once was a partner in a law firm, I am not practicing now, and I certainly am not in a position to be in a client - attorney relationship with anyone who isn't paying me long green, but I am happy to give non-personal general orientation on legal issues so you can better work with your real lawyer.
Drupal menu does not perform well with large taxonomy
I know a lot of you *think* you know what will happen if the taxonomy grows too large, but I can tell you from first hand experience, Drupal does NOT perform well with a large taxonomy. My organization has tens-hundreds of thousands of term levels, and menu.inc does not play nicely.
If anyone out there has had similar experiences, please let me know. I'm in the process of rewriting this module so any help/suggestions would be much appreciated!
Thanks!
This patch can help
This patch opens the door for making different widgets for large taxonomies:
http://drupal.org/node/30993
With this patch I was able to build a comfortable widget to manage 10,000 terms, three-tier hierarchy. It takes some work, but the result is worthwhile. The taxonomy widget lets you select the make, model and series of aircraft from 10,000 choices.
- Robert Douglass
-----
My sites: HornRoller.com, RobsHouse.net
tracking
for future reference