Scaling the web front end

[jcesario]

Yah I was thinking the same exact thing actually.... Its far more a limitation of PHP than anything Zabbix is responsible for though.

[jcesario]

perhaps I could setup APD, maybe hack it into hosts.php or something? http://pecl.php.net/package/apd

[danrog]

How about this for php debugging/profiling?

http://xdebug.org/index.php

I haven't used it personally so I can't say if its output would be useful here.

[nelsonab]

Yah I was thinking the same exact thing actually.... Its far more a limitation of PHP than anything Zabbix is responsible for though.

True, but there isn't any functional framework within the Zabbix frontend for enabling adding debugging to disk for situations for this.

[jcesario]

So this is interesting.... For S&G I let my php threads (we use php-fcgi) spin out of control forever after one of my front end timeouts.

Watching the db I noticed something, that I was basically experiencing what people have been referring to as the "DOS" of profileid. Only this is on the auditlog table...

I see basically 2 types of queries just spammed over and over. Theyve been running for over 3 hours now...

SELECT nextid FROM ids WHERE nodeid=0 AND table_name='auditlog' AND field_name='auditid'
UPDATE ids SET nextid=nextid+1 WHERE nodeid=0 AND table_name='auditlog' AND field_name='auditid'

EDIT: This is on the latest nightly

[nelsonab]

Yep... I saw the same symptoms on my box. It has since gone away but when I did see it it was usually when a new user would begin looking at Zabbix.

[jcesario]

I get this when trying to link templates against hosts... or at least I think. It could be totally unrelated.

[jcesario]

Bump. Really dont want to let this thread sink. This basically renders my zabbix setup useless.

[nelsonab]

Have you done much looking into getting xdebug installed? It looks like the only way to get some really good data is going to be to add a profiler of some kind.

[Alexei]

You may try to enable debug in configuration of user groups for one specific group. Now you have a Debug link in the top header for all front-end screens.

Now if you see that a page is slow or very slow, click on the link to see why it happened.

[jcesario]

Thanks Alexei. I will give that a shot and report back what I find.

[nelsonab]

If you're getting a page timeout the front end debug is pretty much useless. The only way to see the debug information is if you can actually get a full page render. The problem I had had very similar symptoms and all I would ever see was a menu bar. Debug information was only available *after* the page rendered which *never* happened. What would be nice is if there was an ability to turn on debugging to a file. I don't care if actually turning it on requires digging into the source, in fact I would prefer that but something that says "this function is called with these values" and so on would do wonders. (kinda like what I have done with Zabcon)

I realize this may mean huge data dumps, perhaps you could make it more granular requiring levels or only logging when someone has enabled a debug get variable after they have enabled debug in the source (required to prevent a DOS of the system by default).

Otherwise for problems like this the only real option is to learn XDebug, or purchase Zend and use it's profiler.

[jcesario]

Um yah. that did nothing.

replicate problem, wait for page to time out in a few moments (far less than the php max execution time) - Then hit debug and.... nothing... no response. no POST|GET. nada.

[jcesario]

nelsonab. Exactly. Thats exactly the type of problems Im having.

[jcesario]

I will be looking into estimating LOE on getting some kind of profiling in there. However thats not something I have time for right now. Its basically a whole project unto itself.

Im also looking into grabbing a copy of Zend Profiler so I can just use that instead.