Hi,
To solve the n+1 problem I've added counter_cache to most of the 1-N
relations. This has a significant impact, mainly because cards were
showing a lot of counters.
Does it make sense to consider the introduction of counter_cache on Hobo
fields? Probably by adding them in the migration generator?
TF
On 09/30/2010 02:58 AM, kevinpfromnm wrote:
The n+1 query problem is pretty prevalent if you don't use includes on
your parent find. Any place it's becoming a hit, you should add
an :include => :child or [:child1, :child2] or if you need
grandchildren, { :child1 => [:grandchild1, gc2], :child2 => [] } See
standard rails active_record find for exact details on syntax. That's
going to be the majority from hobo, any extra queries will (usually)
be from custom view code and permissions.
It's unfortunately quite difficult to automatically optimize (but
maybe there's something there by using children from viewhints or when
compiling a page, maybe figure out what associations are needed and
add those to a include list used by hobo_* in the controller?).
Anyway, there's no magic bullet for optimizing database queries, just
gotta poke and see what's actually getting called and how you can
minimize it.
As far as I know, there is no performance difference between fixed and
generated. Both are compiled and only difference should be from any
customizations on your part.
Last question, don't know as I haven't got any public facing apps.
On Sep 29, 6:46 pm, Scorpio<[email protected]> wrote:
Hi. I'm beginning to understand now how Hobo works (at long last) and
its no longer a "just make it work" thing for me. I've begun thinking
about some optimization. The first thing that came to mind were
database queries. I've noticed that whenever I call a page with say a
lot of children i get a lot of queries. I've also noticed that there
are a lot of queries in general. Is that normal hobo behavior ? Can it
be optimized in some way ? (sorry for asking a seemingly dumb question
but I figure since Hobo has so much "magic" inside it might just have
a solution for it)
The second issue are the generations of the un-customized pages that
Hobo makes. I've been wondering whats better. fixed show.dryml etc or
the generated ones (load- and performance-wise).
Last but not least. How does the Hobo auto generation and a Hobo app
in general work with search engines when it comes to positioning the
website? are there any issues I need to know or any tedious tasks I
need to undertake to make it work? (I've made Hobo add metadata to a
page HTML-style)
Thanks in advance.
--
You received this message because you are subscribed to the Google Groups "Hobo
Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/hobousers?hl=en.
