Blogs in particular are evilly slow
Permalink 2 users found helpful
This is very confusing to me. I may be missing something obvious, though.
I'm hosted on Dreamhost, and running the most recent version of C5.
My site ishttp://www.hellbendermedia.com/... and I also maintainhttp://www.tranquilreefmassage.com/...
I received a number of emails from customers telling me that the Hellbender Media site was running way too slow. I tended to check the main page, and while it seems slow, it's not seeming to be a killer. But they had me look at my blogs, and that was a different story.
So, I went tohttp://www.webpagetest.org/ with some representative URLs...
Results forhttp://www.tranquilreefmassage.com/...
First View: 6.362 seconds (okay)
Repeat View: 1.515 seconds (great!)
Results forhttp://www.hellbendermedia.com/...
First View: 9.828 seconds (for first load, barely acceptable, but still pretty high)
Repeat View: 5.729 seconds (okay)
but then I hit the blog pages...
Results forhttp://www.hellbendermedia.com/projects/movies/tips/2012_05_03/...
First View: 21.113 seconds (holy balls!)
Repeat View: 27.975 (holy 50% LONGER balls!)
Results forhttp://www.hellbendermedia.com/projects/movies/tips/2012_05_02/...
First View: 26.732 seconds (holy balls!)
Repeat View: 16.018 seconds (somewhat less holy balls!)
Sure, the site's a slug (and fixing that would be great) but the blog pages -- those are KILLING me.
I dug into the waterfall data and found that (for example) of the 26.732 seconds the entire page took to load, it didn't even start rendering until the 25.744 mark.
What in the name of deep-fried crickets am I doing wrong? Is this simply some setting?
I try doing full-page cachiong, but that was just laughable -- the load times soared to over a minute (and at that point, I wind up delivering hand-etched web pages via water-donkey).
I keep the site cache nice and clean, and both sites are hosted on the same host (Dreamhost).
Advice? Suggestions? Professor Backwards says "Pleh! Pleh!"
I'm hosted on Dreamhost, and running the most recent version of C5.
My site ishttp://www.hellbendermedia.com/... and I also maintainhttp://www.tranquilreefmassage.com/...
I received a number of emails from customers telling me that the Hellbender Media site was running way too slow. I tended to check the main page, and while it seems slow, it's not seeming to be a killer. But they had me look at my blogs, and that was a different story.
So, I went tohttp://www.webpagetest.org/ with some representative URLs...
Results forhttp://www.tranquilreefmassage.com/...
First View: 6.362 seconds (okay)
Repeat View: 1.515 seconds (great!)
Results forhttp://www.hellbendermedia.com/...
First View: 9.828 seconds (for first load, barely acceptable, but still pretty high)
Repeat View: 5.729 seconds (okay)
but then I hit the blog pages...
Results forhttp://www.hellbendermedia.com/projects/movies/tips/2012_05_03/...
First View: 21.113 seconds (holy balls!)
Repeat View: 27.975 (holy 50% LONGER balls!)
Results forhttp://www.hellbendermedia.com/projects/movies/tips/2012_05_02/...
First View: 26.732 seconds (holy balls!)
Repeat View: 16.018 seconds (somewhat less holy balls!)
Sure, the site's a slug (and fixing that would be great) but the blog pages -- those are KILLING me.
I dug into the waterfall data and found that (for example) of the 26.732 seconds the entire page took to load, it didn't even start rendering until the 25.744 mark.
What in the name of deep-fried crickets am I doing wrong? Is this simply some setting?
I try doing full-page cachiong, but that was just laughable -- the load times soared to over a minute (and at that point, I wind up delivering hand-etched web pages via water-donkey).
I keep the site cache nice and clean, and both sites are hosted on the same host (Dreamhost).
Advice? Suggestions? Professor Backwards says "Pleh! Pleh!"
this is unacceptably slow. Dreamhost should be faster than that.
If you PM me your login credentials (SSH would be awesome) I'll have one of my techs take a quick look.
If you PM me your login credentials (SSH would be awesome) I'll have one of my techs take a quick look.
(I have to run to class in a minute, but will follow up this afternoon. Thanks!)
Hey Edward,
I went to your sites and through FireBug I saw that your Tranquil website was loading an average of 1.2 sec. per page.
Your Hellbender Media on the other hand was loading anywhere from 7 sec - 10 sec; much slower than what should be happening.
Hey frz,
I can email / submit a request ticket to Dreamhost to see if there is anything that they can do in regards to their servers, but seeing as (and I'm assuming that Edward is too) I'm on their Shared Servers, I don't think that there could be much that they can do.
If you want, I can PM you my FTP / SSH Credentials to my dev site so you can view what I have there. On my dev site I have the caching completely off, and when I do it takes nearly 7 - 10 secs (on average, sometimes longer!) for the pages to load.
I went to your sites and through FireBug I saw that your Tranquil website was loading an average of 1.2 sec. per page.
Your Hellbender Media on the other hand was loading anywhere from 7 sec - 10 sec; much slower than what should be happening.
Hey frz,
I can email / submit a request ticket to Dreamhost to see if there is anything that they can do in regards to their servers, but seeing as (and I'm assuming that Edward is too) I'm on their Shared Servers, I don't think that there could be much that they can do.
If you want, I can PM you my FTP / SSH Credentials to my dev site so you can view what I have there. On my dev site I have the caching completely off, and when I do it takes nearly 7 - 10 secs (on average, sometimes longer!) for the pages to load.
Yeah, I noticed that, too. I sent them a trouble ticket this morning, just in case there's something I'm missing...
You want to see REAL latency, try looking at blog pages on the HBM site, such as the Tip of the Day. Ugh!
Yeah, I was seeing on average on that site now at 32 seconds.
Question - Are your sites on different servers with Deamhost, or are they on the same one?
You can view my site here:http://nerdymike.com
All I have on this are:
Core Concrete5 5.5.2.1
Advanced Content Block
Awkward Slider
The Custom Template for the site I designed.
Question - Are your sites on different servers with Deamhost, or are they on the same one?
You can view my site here:http://nerdymike.com
All I have on this are:
Core Concrete5 5.5.2.1
Advanced Content Block
Awkward Slider
The Custom Template for the site I designed.
"Question - Are your sites on different servers with Deamhost, or are they on the same one?"
I'm pretty sure they're on the same server, but I'd have to confirm that.
I'm pretty sure they're on the same server, but I'd have to confirm that.
Hey there,
I too host on Dreamhost, and while I don't have a blog on my site, I was noticing a significant slowdown compared to other CMS's.
What I had to do to really help speed it up was turn on the full page caching and then go and VISIT every page on the site so that way it will be cached on the server already. That helped quite a bit.
I also have set for PHP as PHP5.3.x FastCGI. It works very well. =)
I too host on Dreamhost, and while I don't have a blog on my site, I was noticing a significant slowdown compared to other CMS's.
What I had to do to really help speed it up was turn on the full page caching and then go and VISIT every page on the site so that way it will be cached on the server already. That helped quite a bit.
I also have set for PHP as PHP5.3.x FastCGI. It works very well. =)
Jeez, I have 600 pages or so...
When I turned on full page caching, page latency rose to more than a minute, before even *I* gave up.
When I turned on full page caching, page latency rose to more than a minute, before even *I* gave up.
You said 600 pages...
My money is on autonav.
If it's written into you theme comment it out. If you don't know how to do that let me know. If it's a Global Block try removing it for a minute and test.
Autonav is famous(at least to me) to dragging sites into the ground once you get over 500 pages.
I'm surprised your memory isn't tanking first.
My money is on autonav.
If it's written into you theme comment it out. If you don't know how to do that let me know. If it's a Global Block try removing it for a minute and test.
Autonav is famous(at least to me) to dragging sites into the ground once you get over 500 pages.
I'm surprised your memory isn't tanking first.
What if you had the blog pages set to be excluded from the Nav. Would that help in keeping the Autonav down?
You'd think, but no. It still runs through them all.
Then, to me that seems a waste there. The query should be structured as such to exclude the rows that have the "Exclude AutoNav" on, and any child pages underneath those kind of pages.
As far as the Breadcrumbs are concerned, that should be easy enough to go from where the page is, and then just up one level, limit 0,1.
I really don't see why it needs to go through ALL of the page records in all of them (especially for the breadcrumbs).
As far as the Breadcrumbs are concerned, that should be easy enough to go from where the page is, and then just up one level, limit 0,1.
I really don't see why it needs to go through ALL of the page records in all of them (especially for the breadcrumbs).
It's been discussed. Many attempts have been made. I'll show you the code in a minute. They don't want to change it, trust me, people have tried.
If the AutoNav slows down a site when it reaches over 500 pages, as a website owner, I see this as a major flaw within the CMS itself, as it feels like I'm being limited by the CMS.
Now, I could just NOT use the AutoNav, and manually build out the menu on the initial creation, but if the AutoNav is there as a core content block, it shouldn't feel so... limiting, especially if you're going to be setting up your site with C5 with a blogging aspect (or any aspect that will have many pages, but not necessarily displayed within the menu).
Now, I could just NOT use the AutoNav, and manually build out the menu on the initial creation, but if the AutoNav is there as a core content block, it shouldn't feel so... limiting, especially if you're going to be setting up your site with C5 with a blogging aspect (or any aspect that will have many pages, but not necessarily displayed within the menu).
This site uses the auto-nav. It has over 300,000 pages. It is not slow.
Something is very wrong with your site. It is impossible to know whether it is a configuration option or not.
Something is very wrong with your site. It is impossible to know whether it is a configuration option or not.
"Something is very wrong with your site."
That's my thinking.
The trick is to figure out what makes it so different.
So I can fix it.
That's my thinking.
The trick is to figure out what makes it so different.
So I can fix it.
Oh strange. I was under the impression that if I had 500 pages under a top level "Blog" in the nav and they were set to "Exclude from Nav" I just ended up with 150MB object.
"This site uses the auto-nav. It has over 300,000 pages. It is not slow."
So, in your opinion, should I not try the mod Chad mentions below?
So, in your opinion, should I not try the mod Chad mentions below?
it's a 2sec change that can easily be changed back. try it and see if it helps. I don't know if it will or won't help you. I was just noting how you would do that.
ChadStrat
ChadStrat
try changing line 475 of the autonav controller to:
ChadStrat
$q = "select Pages.cID from Pages left join CollectionSearchIndexAttributes Attributes on Pages.cID = Attributes.cID where cIsTemplate = 0 and cIsActive = 1 and cParentID = '{$cParentID}' and Attributes.ak_exclude_nav <> 1 {$orderBy}";
ChadStrat
this will remove any exclude_nav page from the query. I believe that's what you want...no?
C
C
Hello Chad,
Yes, that is it. Thank you for finding that so fast (Haven't been able to look into the code yet. =) ).
Yes, that is it. Thank you for finding that so fast (Haven't been able to look into the code yet. =) ).
"...the autonav controller..."
Sorry if this is a dumb question, but that's a file on the server, and not a setting via the dashboard...?
Sorry if this is a dumb question, but that's a file on the server, and not a setting via the dashboard...?
correct. in root /concrete/blocks/autonav/controller.php
C
C
"correct. in root /concrete/blocks/autonav/controller.php"
Coolness. I have to wait until I'm at my FTP client before I can do it, this evening.
Coolness. I have to wait until I'm at my FTP client before I can do it, this evening.
"try changing line 475 of the autonav controller to..."
Implemented the change, flushed the cache, and reran all the various indexing scripts and so forth.
On the plus side, everything seems to run a little faster.
On the neutral side, once I click a link to one of the blog posts, it slugs down to 20+ seconds.
So, I suspect that your suggestion is a good one, but the results suggest that this was not what is causing the huge slugging issue.
Implemented the change, flushed the cache, and reran all the various indexing scripts and so forth.
On the plus side, everything seems to run a little faster.
On the neutral side, once I click a link to one of the blog posts, it slugs down to 20+ seconds.
So, I suspect that your suggestion is a good one, but the results suggest that this was not what is causing the huge slugging issue.
Okay, current status of this thing is as follows:
Tried a couple different themes last night (based on the hypothesis that maybe my theme had a glitch). Different themes responded differently, but there was a consistent response when it came to the blog pages. That response was s-l-o-w.
Implemented the menu fix below (and thank you, Chad!), and while it seemed to slice off load times, when I ran the actual result athttp://www.webpagetest.org/ this is what I got:
Page submitted:
http://www.hellbendermedia.com/projects/movies/tips/2012_05_03/...
First View: (26.581s)
Repeat View: (20.770s)
I ran it again:
First View: (17.110s)
Repeat View: (19.829s)
And again:
First View: (28.202s)
Repeat View: (24.730s)
So, still "holy balls!"
-=-=-=-=-=-=-
My host, Dreamhost, wrote to me this morning telling me that they were a little swamped with support, but were planning on responding to me. So that's back in a low orbit.
-=-=-=-=-=-=-
An intriguing path of exploration was offered by Greg yesterday via PM. He suggests that maybe the issue is that I have nearly 500 blog entries all flat, not subdivided into years/months/etc.
Now, for this particular blog, there isn't a date component to the entries -- it's all just a huge list of tips -- so I'm reluctant to break the entries into date buckets (because no one thinks a tip that's two years old is useful anymore). I'm going to experiment with it today, though, and see how I might be able to do it without using dates or time-related buckets.
If that works, then great, I guess, but I think it seems... a bit patchy. Surely there are blogs out there of a daily sort that have more than 500 entries but aren't slogging...?
Suggestions/questions/observations are all welcome, please! There are things I want to do with this website (such as set up a discussion board), but there's no way I can do them with 10-30 second latency (unless I'm going to focus on the Treant Clientele).
Thanks so far for the discussion and ideas -- I've found it all very helpful!
Tried a couple different themes last night (based on the hypothesis that maybe my theme had a glitch). Different themes responded differently, but there was a consistent response when it came to the blog pages. That response was s-l-o-w.
Implemented the menu fix below (and thank you, Chad!), and while it seemed to slice off load times, when I ran the actual result athttp://www.webpagetest.org/ this is what I got:
Page submitted:
http://www.hellbendermedia.com/projects/movies/tips/2012_05_03/...
First View: (26.581s)
Repeat View: (20.770s)
I ran it again:
First View: (17.110s)
Repeat View: (19.829s)
And again:
First View: (28.202s)
Repeat View: (24.730s)
So, still "holy balls!"
-=-=-=-=-=-=-
My host, Dreamhost, wrote to me this morning telling me that they were a little swamped with support, but were planning on responding to me. So that's back in a low orbit.
-=-=-=-=-=-=-
An intriguing path of exploration was offered by Greg yesterday via PM. He suggests that maybe the issue is that I have nearly 500 blog entries all flat, not subdivided into years/months/etc.
Now, for this particular blog, there isn't a date component to the entries -- it's all just a huge list of tips -- so I'm reluctant to break the entries into date buckets (because no one thinks a tip that's two years old is useful anymore). I'm going to experiment with it today, though, and see how I might be able to do it without using dates or time-related buckets.
If that works, then great, I guess, but I think it seems... a bit patchy. Surely there are blogs out there of a daily sort that have more than 500 entries but aren't slogging...?
Suggestions/questions/observations are all welcome, please! There are things I want to do with this website (such as set up a discussion board), but there's no way I can do them with 10-30 second latency (unless I'm going to focus on the Treant Clientele).
Thanks so far for the discussion and ideas -- I've found it all very helpful!
Could you list all the blocks that are used on a blog page?
"Could you list all the blocks that are used on a blog page?"
You bet!
Most current entry is of type Blog Page
It contains:
* an auto-nav breadcrumb (which I think you already noticed)
* an AddThis block (set to float:right;)
* a content block (I change that for each entry)
* a next-and-previous nav
* a guestbook block
* a slow-the-page-load block.
No, wait, that last one isn't there after all. 8)
Nuttin' else.
You bet!
Most current entry is of type Blog Page
It contains:
* an auto-nav breadcrumb (which I think you already noticed)
* an AddThis block (set to float:right;)
* a content block (I change that for each entry)
* a next-and-previous nav
* a guestbook block
* a slow-the-page-load block.
No, wait, that last one isn't there after all. 8)
Nuttin' else.
Can you disable the autonav breadcrumb and check the site speed?
"Can you disable the autonav breadcrumb and check the site speed?"
Okay, I deleted the breadcrumb and the next-prev block (manually inserted a "back to top" link in a block via the page template)...
Ran three trials on
http://www.webpagetest.org/
for page
http://www.hellbendermedia.com/projects/movies/tips/2012_05_03/...
Trial 1:
First view: 5.260 s
Repeat View: 5.619 s
Trial 2:
First view: 5.679 s
Repeat View: 3.682 s
Trial 3:
First view: 4.801 s
Repeat View: 4.752 s
Okay, I deleted the breadcrumb and the next-prev block (manually inserted a "back to top" link in a block via the page template)...
Ran three trials on
http://www.webpagetest.org/
for page
http://www.hellbendermedia.com/projects/movies/tips/2012_05_03/...
Trial 1:
First view: 5.260 s
Repeat View: 5.619 s
Trial 2:
First view: 5.679 s
Repeat View: 3.682 s
Trial 3:
First view: 4.801 s
Repeat View: 4.752 s
yup.
"Yup"
Redid the page with a somewhat more attractive "back to main page" link.
Ran three trials on
http://www.webpagetest.org/
for page
http://www.hellbendermedia.com/projects/movies/tips/2012_05_03/...
Trial 1:
First view: 5.159 s
Repeat View: 3.706 s
Trial 2:
First view: 8.254 s
Repeat View: 4.933 s
Trial 3:
First view: 7.369 s
Repeat View: 4.313 s
Woot!
Dankon!
Redid the page with a somewhat more attractive "back to main page" link.
Ran three trials on
http://www.webpagetest.org/
for page
http://www.hellbendermedia.com/projects/movies/tips/2012_05_03/...
Trial 1:
First view: 5.159 s
Repeat View: 3.706 s
Trial 2:
First view: 8.254 s
Repeat View: 4.933 s
Trial 3:
First view: 7.369 s
Repeat View: 4.313 s
Woot!
Dankon!
Last two things would be to convert the top nav to a Global Area if it is hardcoded int he theme and place an autonav in it then turn on "Full page caching if blocks support it" and then a full page cache lifetime of 10080(one week) and you should be cruisin
"Last two things would be to convert the top nav to a Global Area if it is hardcoded int he theme and place an autonav in it then turn on "Full page caching if blocks support it" and then a full page cache lifetime of 10080(one week) and you should be cruisin"
By topnav, you mean what used to be the breadcrumbs, or the thing that has all my various drop-downs?
By topnav, you mean what used to be the breadcrumbs, or the thing that has all my various drop-downs?
The various dropdowns. This part is a little confusing if you don't have experience with concrete5 themes. You will need to edit the theme you are using.
I would first try enabling Full page caching with the settings I told you. That might be good enough. And I would definitely use FastCGI 5.3 as the CollectVersion object has circular references that 5.2 does not garbage collect well as I have learned recently.
I would first try enabling Full page caching with the settings I told you. That might be good enough. And I would definitely use FastCGI 5.3 as the CollectVersion object has circular references that 5.2 does not garbage collect well as I have learned recently.
Also, if you want to pm me login details I can check it out real quick and show you the issue.
For everyone else's benefit , this site has over 600 pages :http://whatcom.ctc.edu/
And you can see it runs just fine. At the end of the day....blog posts are pages. It doesn't matter where they are in the sitemap. They may have more attributes attached to them,or more blocks on the page. but # of pages is NOT your issue.
see attached screenshot please.
Addthis is taking on 25 sec of load time to generate on the blog page.
as to the 24s previous to that...that is frankly speaking a server issue.
ChadStrat
And you can see it runs just fine. At the end of the day....blog posts are pages. It doesn't matter where they are in the sitemap. They may have more attributes attached to them,or more blocks on the page. but # of pages is NOT your issue.
see attached screenshot please.
Addthis is taking on 25 sec of load time to generate on the blog page.
as to the 24s previous to that...that is frankly speaking a server issue.
ChadStrat
"For everyone else's benefit , this site has over 600 pages :http://whatcom.ctc.edu/ And you can see it runs just fine. At the end of the day....blog posts are pages. It doesn't matter where they are in the sitemap. They may have more attributes attached to them,or more blocks on the page. but # of pages is NOT your issue."
I was kinda figuring. I didn't think it should matter that much.
"Addthis is taking on 25 sec of load time to generate on the blog page."
I deleted the AddThis block from the page and ran tests:
Test page:
http://www.hellbendermedia.com/projects/movies/tips/2012_05_03/...
I ran three trials:
Trial 1:
First View: (16.663s)
Repeat View: (23.765s)
Trial 2:
First View: (21.373s)
Repeat View: (17.704s)
Trial 3:
First View: (21.957s)
Repeat View: (17.024s)
This seems somewhat better. Maybe on the right track...?
"as to the 24s previous to that...that is frankly speaking a server issue."
Yeah, waiting to hear back from my server on that. I have somewhat limited capability to modify things on that end, but any advice is welcome.
Thanks, this has been very useful!
I was kinda figuring. I didn't think it should matter that much.
"Addthis is taking on 25 sec of load time to generate on the blog page."
I deleted the AddThis block from the page and ran tests:
Test page:
http://www.hellbendermedia.com/projects/movies/tips/2012_05_03/...
I ran three trials:
Trial 1:
First View: (16.663s)
Repeat View: (23.765s)
Trial 2:
First View: (21.373s)
Repeat View: (17.704s)
Trial 3:
First View: (21.957s)
Repeat View: (17.024s)
This seems somewhat better. Maybe on the right track...?
"as to the 24s previous to that...that is frankly speaking a server issue."
Yeah, waiting to hear back from my server on that. I have somewhat limited capability to modify things on that end, but any advice is welcome.
Thanks, this has been very useful!
now captcha is hurting you. 4sec pre page load right there. see attached.
ProBlog uses Discuss, which loads in after page load. kinda nice.
ChadStrat
ProBlog uses Discuss, which loads in after page load. kinda nice.
ChadStrat
so looks like all said and done, you should be able to get this down to 12sec. Not great...but livable. This can only be improved by a better shared hosting solution.
ChadStrat
ChadStrat
"You'd think, but no. It still runs through them all."
I see a similarly long delay when I open up the Pagemap, too, especially when I expand to look at all the blog posts.
I see a similarly long delay when I open up the Pagemap, too, especially when I expand to look at all the blog posts.
"What if you had the blog pages set to be excluded from the Nav."
They all are. Sorting through all those pages would be crazymaking on the menu! 8O
They all are. Sorting through all those pages would be crazymaking on the menu! 8O
"If you don't know how to do that let me know..."
Letting you know. 8)
Letting you know. 8)
First post ever. About Time.
mkly: you are right about autonav - I have a site that I'm scaling up - it has 500 pages in it now - soon to be 2000+
Thing is I was able to incrementally add the pages and see the performance dropping.
With autonav hardcoded in GlobalArea in the header I was getting 12sec page loads on the home page. Comment it out and that dropped to < 2sec.
It came down to site structure for me. My autonav was taking the top level of pages and one sub level like so:
One of the pages at the top level is a parent holder for about 500 pages. If I limited the autnav to only look at the top level then the speed was great. add the second level and it went to sludge.
SO - I created another top level page and moved the parent and 500 pages into that and now things are running fast again.
All the 500 sub pages have the exclude from nav attribute, but the auto-nav still seems to want to go through them all somehow.
This may not help, but I thought it may shed some light. Thanks to the C5 team.
mkly: you are right about autonav - I have a site that I'm scaling up - it has 500 pages in it now - soon to be 2000+
Thing is I was able to incrementally add the pages and see the performance dropping.
With autonav hardcoded in GlobalArea in the header I was getting 12sec page loads on the home page. Comment it out and that dropped to < 2sec.
It came down to site structure for me. My autonav was taking the top level of pages and one sub level like so:
$nav = BlockType::getByHandle('autonav'); $nav->controller->displayPages = "top"; $nav->controller->displaySubPages = "all"; $nav->controller->displaySubPageLevels = "custom"; $nav->controller->displaySubPageLevelsNum = 1; $nav->controller->orderBy = 'display_asc'; $nav->render('view');
One of the pages at the top level is a parent holder for about 500 pages. If I limited the autnav to only look at the top level then the speed was great. add the second level and it went to sludge.
SO - I created another top level page and moved the parent and 500 pages into that and now things are running fast again.
All the 500 sub pages have the exclude from nav attribute, but the auto-nav still seems to want to go through them all somehow.
This may not help, but I thought it may shed some light. Thanks to the C5 team.
Oh and is that breadcrumb the autonav breadcrumb template? Double autonav goodness.
"Oh and is that breadcrumb the autonav breadcrumb template? Double autonav goodness."
Probably is -- breadcrumbs aren't necessary, though. I probably added them back in the Stone Age when I was carving the site into existence.
Probably is -- breadcrumbs aren't necessary, though. I probably added them back in the Stone Age when I was carving the site into existence.
Okay, so here's a thought...
Would it make more sense to use this Add-On:
http://www.concrete5.org/marketplace/addons/wordpress-for-concrete5...
and have the filmmaking blog be an actual WP install running under C5?
As a rule, I don't like using WP because it's hacktastic, and Dreamhost appears to have certain... flaws regarding the security of their WP installations. BUT, if this (as hokey a fix as it seems) is a way to bypass C5's (possibly) difficulty in tracking 500+ blog entries, then maybe that's a patch that I can slap on until such time as Magic Occurs...?
Thoughts?
Would it make more sense to use this Add-On:
http://www.concrete5.org/marketplace/addons/wordpress-for-concrete5...
and have the filmmaking blog be an actual WP install running under C5?
As a rule, I don't like using WP because it's hacktastic, and Dreamhost appears to have certain... flaws regarding the security of their WP installations. BUT, if this (as hokey a fix as it seems) is a way to bypass C5's (possibly) difficulty in tracking 500+ blog entries, then maybe that's a patch that I can slap on until such time as Magic Occurs...?
Thoughts?
I disagree. I dont' think C5 # of pages has anything to do with the load time of any given single page. C5's optimized tables don't work like that. Pages are accessed by either cache,path, or cID. All three scenarios have direct data loading. Completely irrespective to any other pages and data in the site.
Again....Addthis is adding 25sec to your page load in the case of Blogs. remove that, and those pages load as fast as any other page on the site.
ChadStrat
Again....Addthis is adding 25sec to your page load in the case of Blogs. remove that, and those pages load as fast as any other page on the site.
ChadStrat
@chad No problem. I work on these problems pretty much daily with people. You're entitled to that for sure. And this particular case could certainly be anything.
Autonav(or blocks based of it) end up 3 out of 4 times the problem in my experiences with sites I'll come in to assist with that have a high page count.
If you would like to go over the details of how autonav builds it's navItems and the recursion in a CollectionVersions attribute property array send me a pm and I'd be more than happy to go into the details.
Autonav(or blocks based of it) end up 3 out of 4 times the problem in my experiences with sites I'll come in to assist with that have a high page count.
If you would like to go over the details of how autonav builds it's navItems and the recursion in a CollectionVersions attribute property array send me a pm and I'd be more than happy to go into the details.
I was not disagreeing with you mlky? lol
I was disagreeing with the notion that you should abandon C5 for a 600 page site in favor of a half-bake wordpress mix. lol sorry I was not more clear.
however, please share your wisdom if you would:
1 - how does cutting off the query at the pass by joining the search with exclude-nav in the collectionsearchindex not, for the most part, eliminate the number of superfluous pages in the recursion? (my earlier suggested quick fix)
2 - why do you not have a better, more efficient nav package released for use? since you obviously have this down pat? job security? lol ha ha
Chad
I was disagreeing with the notion that you should abandon C5 for a 600 page site in favor of a half-bake wordpress mix. lol sorry I was not more clear.
however, please share your wisdom if you would:
1 - how does cutting off the query at the pass by joining the search with exclude-nav in the collectionsearchindex not, for the most part, eliminate the number of superfluous pages in the recursion? (my earlier suggested quick fix)
2 - why do you not have a better, more efficient nav package released for use? since you obviously have this down pat? job security? lol ha ha
Chad
never mind on q#1 - I see now the error of my thinking on that. because it's still including children of those excluded pages, and 3 out of 4 time users will exclude the parent, but not all it's children.
Chad
Chad
you could probably join in cParentID and even grandparent ID exclusions as well. that would head off superfluous pages pretty well.
Seems like the whole point of the attribute "exclude_nav" and to be honest, until this thread, I was largely un-aware that the autonav still included those and parsed them out in the view layer.
This is a problem that need Git pull asap in my opinion.
C
Seems like the whole point of the attribute "exclude_nav" and to be honest, until this thread, I was largely un-aware that the autonav still included those and parsed them out in the view layer.
This is a problem that need Git pull asap in my opinion.
C
I should add that it is a pretty sticky problem with lots of pot holes.
Example: Say you wanted to create a new autonav template that honoured a new checkbox attribute called "Baseball Player?" and didn't want to show it. You have to do that in the view after the first array is built or you have to override the entire controller file and never upgrade autonav. At this point I think I know enough c5 tricks to deal with this and others at this point so hopefully it will work out.
Thanks for having a nice clean discussion on this. It's great to here ideas from someone who has the level of understanding that you have about c5.
Example: Say you wanted to create a new autonav template that honoured a new checkbox attribute called "Baseball Player?" and didn't want to show it. You have to do that in the view after the first array is built or you have to override the entire controller file and never upgrade autonav. At this point I think I know enough c5 tricks to deal with this and others at this point so hopefully it will work out.
Thanks for having a nice clean discussion on this. It's great to here ideas from someone who has the level of understanding that you have about c5.
#2 haha ya I know. I really should. But usually you can avoid it well enough if you change the directory structure or use manual nav or just get it in a Global Area with a server that has enough ram to cache that first run.
@jordanlev attempted some pulls with autonav and I believe I've seen others. Now that @jordanlev's pull didn't go through, I think you are very correct in that someone(guess I kind of volunteered myself with this thread) needs to write a modern autonav.
EDIT: To be clear I'm not bashing the person(s) who wrote autonav. It just got Frankensteined after a while, probably for some business type reasons beyond the developers control.
@jordanlev attempted some pulls with autonav and I believe I've seen others. Now that @jordanlev's pull didn't go through, I think you are very correct in that someone(guess I kind of volunteered myself with this thread) needs to write a modern autonav.
EDIT: To be clear I'm not bashing the person(s) who wrote autonav. It just got Frankensteined after a while, probably for some business type reasons beyond the developers control.
I think a more likely reason is it being present in the build of C5 long before other aspects were developed...and just never re-designed.
I think you should develop one. It's definitely a need here for larger sites.
C
I think you should develop one. It's definitely a need here for larger sites.
C
Use this file at the root of your site.
Will enable you serve to serve the content conpressed and more eficiently.
I see it you can do a lot of optimization on a server level.
or here his the code for .htaccess
Will enable you serve to serve the content conpressed and more eficiently.
I see it you can do a lot of optimization on a server level.
or here his the code for .htaccess
# -- concrete5 urls start -- <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME}/index.html !-f RewriteCond %{REQUEST_FILENAME}/index.php !-f RewriteRule ^(.*)$ index.php/$1 [L] </IfModule> # -- concrete5 urls end -- # ---------------------------------------------------------------------- # Better website experience for IE users # ---------------------------------------------------------------------- # Force the latest IE version, in various cases when it may fall back to IE7 mode # github.com/rails/rails/commit/123eb25#commitcomment-118920
Viewing 15 lines of 260 lines. View entire code block.
Helpful discussion, thanks!
I've always hard-coded my auto-navs in and now I've seen the Global Area light :-)
One other thing I wanted to add/re-inforce is how much of an effect third-party resources can have on page speed. Examples are Twitter feeds, RSS displays, and the like.
I had a site that was soooo sloooow, sometimes over a minute a page load. After a lot of hair loss we finally figured out it was a Twitter call through PHP that was dragging everything down. To my knowledge, any call through PHP (eg cURL) has to finish before any part of the page will get sent to the browser. Huge bottleneck.
Our solution was to use Javascript to make the call *after* the page loads. Ironically it is much, much faster overall.
Something to consider if encountering slow load times.
I've always hard-coded my auto-navs in and now I've seen the Global Area light :-)
One other thing I wanted to add/re-inforce is how much of an effect third-party resources can have on page speed. Examples are Twitter feeds, RSS displays, and the like.
I had a site that was soooo sloooow, sometimes over a minute a page load. After a lot of hair loss we finally figured out it was a Twitter call through PHP that was dragging everything down. To my knowledge, any call through PHP (eg cURL) has to finish before any part of the page will get sent to the browser. Huge bottleneck.
Our solution was to use Javascript to make the call *after* the page loads. Ironically it is much, much faster overall.
Something to consider if encountering slow load times.
I've gone through the Five Best Things post (and thanks kindly!) and done of those what I can, but the result so far is no meaningful improvement.
I could try changing the PHP Mode on my host. The options are:
* PHP 5.2.x CGI
* PHP 5.2.x FastCGI (default) (my current choice)
* PHP 5.3.x CGI
* PHP 5.3.x FastCGI
But I have no idea if that'll do the trick.