Slowness?

[Michael Heilemann]

Hey,

Anyone out there with a large database that's experiencing slowdowns when entering the admin? My site is really fast on the outside, but clicking 'edit' on an entry has me waiting for 10 seconds (!) for the admin to come up.

Is there something I can do about this? Am I the only one experiencing it?

--
Michael Heilemann
http://binarybonsai.com

[Owen Winkler]

Michael Heilemann wrote:
>
> Anyone out there with a large database that's experiencing slowdowns
> when entering the admin? My site is really fast on the outside, but
> clicking 'edit' on an entry has me waiting for 10 seconds (!) for the
> admin to come up.
>
> Is there something I can do about this? Am I the only one experiencing it?

Habari reports that I have 2735 posts. When I click edit on any of them
it comes up immediately.

The code that fetches your post for display is the same that's used to
fetch it for editing. The only difference on the publish page that I
can think of is if you have other plugins activated that interact with
that page. I don't know of any that would cause the page to slow down
noticeably like you describe, though.

Owen

[Chris J. Davis]

It could be one of the silo's. If flickr is having a rough day for
instance, it will slow down the loading of the page. Sometime it
breaks the loading of the page entirely with a cURL timeout error.

Need to do something about that.

Chris

[Owen Winkler]

Chris J. Davis wrote:
> It could be one of the silo's. If flickr is having a rough day for
> instance, it will slow down the loading of the page. Sometime it
> breaks the loading of the page entirely with a cURL timeout error.

The content of the media browser is loaded via Ajax only when the tab
for it is clicked. It shouldn't affect the load speed of the publish
page. At least that's the intended function.

> Need to do something about that.

If curl is affecting the load of the publish page somehow due to the way
a silo works, then yes, that should be squashed quickly.

Owen

[Chris J. Davis]

Hey Mike, do me a favor and open the activity window in Safari and
load the write page. See if any of the resources it is trying to load
and slowing it down.

Chris

[Rich Bowen]

On Aug 12, 2008, at 08:43, Owen Winkler wrote:

Need to do something about that.

If curl is affecting the load of the publish page somehow due to the way 
a silo works, then yes, that should be squashed quickly.

I get curl timeout messages on a once-a-week basis.

Just out of curiosity, why are we using curl rather than HTTP::Request or other less archaic method?

--

Rich Bowen

rbo...@rcbowen.com

[Owen Winkler]

Rich Bowen wrote:
>
> I get curl timeout messages on a once-a-week basis.

You get curl timeout messages on the publish page, or the dashboard? On
the dashboard, I understand this error. On the publish page, I do not.

> Just out of curiosity, why are we using curl rather than HTTP::Request
> or other less archaic method?

We actually have a Habari class, RemoteRequest, that abstracts the curl
call, just like HTTP::Request would.

Owen

[Rich Bowen]

On Aug 12, 2008, at 09:13, Owen Winkler wrote:

Rich Bowen wrote:

I get curl timeout messages on a once-a-week basis.

You get curl timeout messages on the publish page, or the dashboard?  On
the dashboard, I understand this error.  On the publish page, I do not.

It usually happens on initial load of the dashboard.

Just out of curiosity, why are we using curl rather than HTTP::Request

or other less archaic method?

We actually have a Habari class, RemoteRequest, that abstracts the curl
call, just like HTTP::Request would.

I don't believe HTTP::Request abstracts curl, since you don't have to have curl or libcurl installed to use it. It makes direct HTTP connections. It's noticeably faster - I switched to it for a project I'm working on, and the difference was immediately obvious.

--

If you miss this moment

You miss your life

[Michael Heilemann]

I think the tags tab is causing some serious slowdowns; whether it's a part of this problem or not is something else. It seems to load all my tags (1201) as part of the editing page, which is entirely unnecessary (I personally think the tags tab itself is unnecessary, but that's another discussion).

[Blake Johnson]

> You get curl timeout messages on the publish page, or the dashboard?  On
> the dashboard, I understand this error.  On the publish page, I do not.
>

I have actually been getting the occasional CURL timeout message when
trying to publish a post.

--Blake

[Michael Bishop]

On Aug 12, 9:13 am, Owen Winkler <epit...@gmail.com> wrote:
> Rich Bowen wrote:
>

> > I getcurltimeout messages on a once-a-week basis.
>
> You getcurltimeout messages on the publish page, or the dashboard?  On

> the dashboard, I understand this error.  On the publish page, I do not.
>

I'm experiencing CURL errors on a local install with no plugins active
as well as a live site when trying to edit a post. I'm wondering if
it's releated to the "closed" ticket http://trac.habariproject.org/habari/ticket/349

~miklb


> > Just out of curiosity, why are we usingcurlrather than HTTP::Request

[Michael Heilemann]

On Mon, Aug 18, 2008 at 10:29, Michael Bishop <miklb....@gmail.com> wrote:

I'm experiencing CURL errors on a local install with no plugins active
as well as a live site when trying to edit a post.  I'm wondering if
it's releated to the "closed" ticket http://trac.habariproject.org/habari/ticket/349

How can I see if it's a CURL error? (what is CURL?)

[Michael Heilemann]

Alright, so this is a serious problem for me. It is rendering Habari largely useless. And I'm kind of in the dark as to what I can tell my support guy. After all, it worked pretty flawlessly on WordPress.

Any pointers?

[Chris J. Davis]

Have we actually found out what the problem is? 

Is the slowdown due to the tags being loaded? Or is there a problem with cURL timeouts? I only get cURL timouts when I try to publish a post. It would be interesting to see if the problem is related to flickr, or the pingback plugin.

I really need to write that autocomplete tag code to replace the tag tab.

Chris

[Ali B.]

On Mon, Aug 18, 2008 at 11:40 AM, Michael Heilemann <heil...@gmail.com> wrote:

On Mon, Aug 18, 2008 at 10:29, Michael Bishop <miklb....@gmail.com> wrote:

I'm experiencing CURL errors on a local install with no plugins active
as well as a live site when trying to edit a post.  I'm wondering if
it's releated to the "closed" ticket http://trac.habariproject.org/habari/ticket/349

How can I see if it's a CURL error? (what is CURL?)

Add define ('DEBUG', true); to your config.php

--
Ali B / dmondark
http://www.awhitebox.com

[Michael Heilemann]

On Thu, Aug 21, 2008 at 14:06, Chris J. Davis <c...@chrisjdavis.org> wrote:

Have we actually found out what the problem is? 

No, that's the disturbing thing :) -- If only I knew. Having turned off all plugins, it takes 19 seconds to load my latest entry.

I _think_ it might have something to do with the tags, so if there's a way to turn them off, I'd love to do that and see what happens.

- Mike

[Ali B.]

On Thu, Aug 21, 2008 at 3:19 PM, Michael Heilemann <heil...@gmail.com> wrote:

I _think_ it might have something to do with the tags, so if there's a way to turn them off, I'd love to do that and see what happens.

If you mean disabling displaying the tags in the publish form, here is how to do it: super hacky, but at least you can use it to test:
Just change line 504 of adminhandler.php from $tags= Tags::get(); to $tags=array();
And line 505 from $max= Tags::max_count(); to $max=0;

Let us know if it works out.

[Michael Heilemann]

I'm not 99.9% sure it's the tags that are the problem.

Does anyone use that panel? For making spelling is correct perhaps? I've always found it redundant, but at least I can turn it off now, even if it's hacky. Thanks Ali.

I've documented it here: http://trac.habariproject.org/habari/ticket/600

[Matt Read]

On Thu, Aug 21, 2008 at 8:19 AM, Michael Heilemann <heil...@gmail.com> wrote:
> On Thu, Aug 21, 2008 at 14:06, Chris J. Davis <c...@chrisjdavis.org> wrote:
>
>> Have we actually found out what the problem is?
>
> No, that's the disturbing thing :) -- If only I knew. Having turned off all
> plugins, it takes 19 seconds to load my latest entry.
>
> I _think_ it might have something to do with the tags, so if there's a way
> to turn them off, I'd love to do that and see what happens.

can you try the following:

1) add define('DEBUG', true); to your config.php

2) add the following code to your theme, footer.php will do:

include HABARI_PATH . '/system/admin/db_profiling.php';

3) load the page that is causing the slowness with ?db_profile
appended. eg. http://example.com/foo?db_profile. Also note that the
admin already has this functionality built in, so you can just add
?db_profile to any admin url.

4) copy and paste the output, or just examine the output to see if any
queries are taking long amounts of time. eg. you will see the actual
sql query followed by the time to execute it:

SELECT * FROM habari__sessions WHERE token = ?

Time to Execute: 0.00048828125

I doubt that any of the queries will be causing the slowness. It is
most likely do to RemoteRequest which has a default timeout of 2 min,
iirc. So if no queries are causing it try:

1) line 48 of system/classes/remoterequest.php looks like:

public function __construct( $url, $method= 'GET', $timeout= 180 )

Change the timeout to something smaller, say 5. (that is in seconds).
so it should read:

public function __construct( $url, $method= 'GET', $timeout= 5 )

2) load the page causing problems, and see if that made it faster. If
so, we will have to do some backtracing to see what code is causing
the timeout...

[Matt Read]

On Thu, Aug 21, 2008 at 12:09 PM, Matt Read <matt....@gmail.com> wrote:
> 4) copy and paste the output, or just examine the output to see if any
> queries are taking long amounts of time. eg. you will see the actual
> sql query followed by the time to execute it:

Also note you must logged in to use that...

[Ali B.]

On Thu, Aug 21, 2008 at 7:03 PM, Michael Heilemann <heil...@gmail.com> wrote:

I'm not 99.9% sure it's the tags that are the problem.

But did it increase the performance after you disabled it?

Does anyone use that panel? For making spelling is correct perhaps?

I do. But then again, I don't have much tags. And yes, I use it for making sure that I am using the same tag I want to use. I have absolutely no problem now of removing it though. The autocomplete would work and even if we don't do that, I can move that panel to a plugin.
 

I've always found it redundant, but at least I can turn it off now, even if it's hacky. Thanks Ali.

Always a pleasure to help.

[rick c]

I use the panel and don't find it redundant at all. I prefer it to
autocomplete. I can see that many people wouldn't have much use for
it, though, and agree that if possible, the tags shouldn't be loaded
into it until they're needed. There's no reason to wait seconds for
the publish page to load.

Rick

On Aug 21, 12:03 pm, "Michael Heilemann" <heilem...@gmail.com> wrote:
> I'm not 99.9% sure it's the tags that are the problem.
> Does anyone use that panel? For making spelling is correct perhaps? I've
> always found it redundant, but at least I can turn it off now, even if it's
> hacky. Thanks Ali.
>
> I've documented it here:http://trac.habariproject.org/habari/ticket/600
>
>
>

> On Thu, Aug 21, 2008 at 14:30, Ali B. <dmond...@gmail.com> wrote:

[Andy C]

I rarely use the Manage-Tags panel because my set of tags is fairly
static but I have just accessed the screen.

I see all my tags in a tag cloud with small, medium and large tags.
Nice touch.

Each tag also has a numeric superscript that indicates how many posts
contain that tag. Nice touch.

As noted elsewhere, the text box at the top of the screen is actually
a dynamic search that displays tags matching the search term which is
neat but not completely obviious. Nice touch.

So I click on the 'uncategorized' because I want to review such posts
and potentially assign a sensible category. I expected to see all
posts tagged as 'uncategorized' displayed with an Edit /Delete (just
like Manage-Entry) but I don't. I just see options to 'Rename; or
'Delete' this tag. Not that useful - I hardly ever delete a tag and
would only rename to fix a typo (rarely).

Just my $0.02.

[Chris Meller]

Can we bump the tags conversation into its own thread?

Michael: Did you check your server's error_log to see if, perhaps, there were any errors Habari didn't manage to trap?

[Michael Heilemann]

I didn't explain properly: Removing the tags from the publish page sped up things tremendously. It is now fast and wonderful.

[Chris Meller]

Spiffy. You'd mentioned several other problems along the way in various places - are there any left still causing you problems?

[Arthus Erea]

I think it is worth considering moving the tags tab to a plugin. However, it should be a default plugin.

For many users, it is unnecessary but doesn't do any damage.

For some, it is a useful tool.

For a small minority (Michael), it significantly decreases the scalability.

[Michael Heilemann]

On Fri, Aug 22, 2008 at 01:57, Chris Meller <ch...@doesnthaveone.com> wrote:

Spiffy. You'd mentioned several other problems along the way in various places - are there any left still causing you problems?

There's the search not working across the board. It looks like this is the error the frontend throws:

Undefined variable: criteria in /var/www/vhosts/binarybonsai.com/httpdocs/user/themes/kalamari/search.php line 6 on request of "/search"

 

The admin doesn't throw anything, but isn't working either.

- Mike

On Thu, Aug 21, 2008 at 5:27 PM, Michael Heilemann <heil...@gmail.com> wrote:

I didn't explain properly: Removing the tags from the publish page sped up things tremendously. It is now fast and wonderful.

On Thu, Aug 21, 2008 at 18:10, Matt Read <matt....@gmail.com> wrote:

On Thu, Aug 21, 2008 at 12:09 PM, Matt Read <matt....@gmail.com> wrote:
> 4) copy and paste the output, or just examine the output to see if any
> queries are taking long amounts of time. eg. you will see the actual
> sql query followed by the time to execute it:

Also note you must logged in to use that...

--

Michael Heilemann
http://binarybonsai.com

[Arthus Erea]

This is definitely a problem with your theme.

You need to make sure 2 things:

1) The search form has the correct names and ids. Look at K2 for reference.

2) Your template checks to make sure $criteria is set before actually displaying it.

[Michael Heilemann]

On Fri, Aug 22, 2008 at 08:53, Arthus Erea <arthu...@gmail.com> wrote:

This is definitely a problem with your theme.

You need to make sure 2 things:

1) The search form has the correct names and ids. Look at K2 for reference.

2) Your template checks to make sure $criteria is set before actually displaying it.

The same thing happens on the other templates, _and_ in the admin.
 

[Chris J. Davis]

We need to check and make sure the default rewrite rules were installed correctly. I have not seen or heard of this before (search not working) it is working on all my sites running Habari.

I will do a fresh install today and see if I can reproduce the errors.

Chris

[Michael Heilemann]

On Fri, Aug 22, 2008 at 13:22, Chris J. Davis <c...@chrisjdavis.org> wrote:

We need to check and make sure the default rewrite rules were installed correctly. I have not seen or heard of this before (search not working) it is working on all my sites running Habari.

I haven't had the time to look into it properly these last few days, but hopefully during the weekend.