- i successfully managed to migrate via feeds module 44,000+ nodes to a cck content type called 'candidates'.
- data is composed of candidates for an election, with taxonomy fields including: region, town or city, political party, province name, and so on, 5 fields are taxonomy term reference fields.
- via views i hope to create a page which segregates candidates per area (in this case, region). Also hoping to do a glossary of candidates within a region or regardless of region. Basically I just want to experiment until I get a nice page.
- the first page i tried to make is one that segregates per region by creating a relationship 'content taxonomy terms on node', and used that on Contextual Filters. I turned off paging and any sorting. I am just loading the field content: title.
- Problem: When I enter the url /candidates it just loads and loads and nothing appears.
- Any suggestions appreciated!
Comments
Comment #1
ghmercado commentedany help?
Comment #2
Mołot commentedWhat are your pager settings?
What are you filtering on?
What are you grouping on?
Does the 2 above create any "having" clausules?
Do you have indexes on columns you are using for joins and filters?
Does your setup work all right for 40, 400, 4`000 nodes?
Also, please don't put the same question many times, it wastes time of ppl like me, browsing issues to help.
Comment #3
ghmercado commented- pager settings are 'display a specified number of items: 10 items', more link: no
- there is no sort criteria
- filter criteria is just published (yes) and content type: candidate.
- i made a relationship 'Content: Taxonomy terms on node' and used that to make a filter 'taxonomy term: name'.
- taxonomy term: name configuration is: display a summary, descending, sort by no. of records, format: list, display record count with link (checked).
- i dont know how to answer 'what are you grouping on'
- i dont know how to answer 'having clausules'
- i dont know how to answer 'joins or filters'
- my setup is a linode 1024mb, 8 CPU (1x priority). im hoping that's enough
thanks so much for the assistance and apologies for 2x post I was afraid I was being too verbose
Comment #4
Mołot commentedpager - so far so good, should not abuse your site with to much results at once
filter - publishet and content type are pretty well done and hard to break
In views ui settings check "show SQL" option and just paste your view's SQL here.
My blind bet now is "sort by no. of records" - it means drupal needs to execute count on nodes for each of taxonomy records, right? So it may need to scan all your nodes. Worst case scenario is node number * taxonomy number of tests with full scan on nodes. If that's what happening, your setup will be only good for about 1000~5000 nodes. Hardly enough RAM to load substantially more.
Could you test if it works with smalles amounts of data, by the way?
Comment #5
ghmercado commentedpreviously i turned off 'automatically update preview on changes' because the live preview just keeps loading as well. I clicked 'show the sql query' on your suggestion but it shows nothing. i clicked the 'auto preview' box and again preview just loads.
i had also changed the sort by from number of records to alphabetical (the only alternative).
I've done this before although not with the same data and with far less nodes, so I'm sure it works. So this is a case of just underpowered server specs you think? Will indexing via search help? it's only indexed 2%. I'm desperate for suggn's. What if I do this offline on my laptop and migrate when done?
Comment #6
Mołot commentedSearch index has nothing to do with it.
Get down to the number of nodes your system can work with. Preferably one near the upper border. Then we'll get to optimization. After that we can try full load again.
Your system is not underpowered, it's just your query is abusive. But I need to see it to help!
And quick suggestion - switch from taxonomy term name to taxonomy term id. It's way easier for SQL and you can fix display in tpl anyway.
Comment #7
ghmercado commentedso if i, say, manage to get it to work with ten percent as much nodes, i can then add another ten percent and so on?
what do you think of that strategy?
Comment #8
Mołot commentedIf you'll get down to 10% nodes and it will "almost work", you will know you need to make query at least 10 times faster to get it work with 100% of nodes. Simple as that. But I don't see how could you repair your queries when you don't really see them.
And it's no magic, adding nodes in 10% batches will not help. Anything that invalidates views' cache forces module to re-scan your data. So you simply need it to be fast enough not to break on production, full data set in case of cache invalidation.
Do you have access to slow query log? if so, maybe there you'll be able to see your querry. Biggest, nastiest baddass in that log, I bet.
Comment #9
ghmercado commentedi only have a /var/log/mysql/error.log, no slow query log. Would that do?
Comment #10
Mołot commentedTalk to your sysadmin. You have some instability at the very basic level, storage engine abstraction layer it seems. As long as your InnoDB fails and starts, your server is to busy keeping itself up to do any significant job for you. Either fix InnoDB or (worst case) get rid of it.
And sorry, but no, error log is not enough. You need to properly configure this: http://dev.mysql.com/doc/refman/5.5/en/slow-query-log.html (simply substitute 5.5 with your mysql version if needed). Without actual SELECT ... FROM ... and so on we are blind. You simply need to get it, either from MySQL end or Drupal end, your choice.
Comment #11
Mołot commentedQuick'n'Dirty:
Comment #12
mustanggb commented