I use PHPEd to debug an application that makes a large number of Ajax requests to execute timed tasks (the app is refreshing status information on a dashboard page). "Run > Debug Session" is ON, because I need to be able to set breakpoints in PHP code being called via Ajax. That works fine - but the IDE starts a new debug session every time an Ajax request is received. You can see this happen in the IDEs Log window, every fraction of a second there is a new "Starting debug session" and "debug session finished". This has a major impact on the IDEs performance, as IDE windows are constantly refreshing and it makes the Editor slow. Is there any way to make it stop doing this, while still being able to set breakpoints in code called via Ajax? Thanks in advance for your help!

If your client calls your server too frequently, why don't you try to relax it?
You can analyze DBGSESSID cookie and if it is set, just make longer timer periods before each ajax call.
IDE can't fix this for you.
IDE can't stop responding to the debugger requests that your client initiates, otherwise you'll first ask us why the breakpoints do not work.

Alternatively, if you know that some (or all) your ajax requests should not trigger debugger, just add DBGSESSID=-1 into URL they call as a GET parameter

Hi Dmitri,

Thank you, I think you answered my question. I understand that the debugger needs to respond to requests in order for breakpoints to work. My question was, did it need to create a new debug session on every incoming request?

I'll try your suggestion about adding DBGSESSID=-1 into the URL for requests that should not trigger the debugger (most of them) - that may be the solution I was looking for.

Regards,
Gordon

Hello again,

After trying your suggestion to set "DBGSESSID=-1" in requests where I do not want to trigger a new debug session, I am finding it works *too* well. Once any request has been made with that parameter set, then *all* breakpoints stop working, even those relating to a request that does NOT have it set. So I'll need to seek another solution. I wonder if I can use DebugBreak() as an alternative to breakpoints in the code? I've seen various references to it, but no actual documentation of how it works. Can you help? Thank you.

try "DBGSESSID=1;s=0"

Thank you, Dmitri, this is definite progress. However, I am finding that, once it stops at _any_ breakpoint, it re-activates debug sessions for *all* requests, including those where "DBGSESSID=1;s=0" is set. In other words:
(1) Launch the app from PHPEd; "DBGSESSID=1;s=0" is set for selected requests where I do not want it to start debug sessions. Working as hoped!
(2) Set a breakpoint for a request where I DO want to debug; again, works as hoped, the breakpoint works. However:
(3) After stopping at a breakpoint in (2), it starts creating new debug sessions again from requests where DBGSESSID=1;s=0" is set

sorry for typo, I meant "DBGSESSID=-1;s=0"
It shouldn't reset cookie

Unfortunately, that stops all breakpoints from working, even when "DBGSESSID=-1;s=0" is not part of the request. Any other suggestions? Otherwise, I think I should try DebugBreak instead.

What we need is a request that won't trigger debug session (it's what -1 is for) but it should not cancel all further sessions (it's what c=0 is for). I'm sorry for the 2nd typo.
Can you try DBGSESSID=-1;c=0 ?
FYI DBGSESSID syntax is described here http://www.nusphere.com/kb/technicalfaq/faq_dbg_related.htm

gskramer, you may want to give a try to Fiddler (i hope that i don't break any rules by posting this). You can easily make it remove particular cookie(s) for say requests that start with or contain particular string ... it has very comprehensive scripting capabilities which allows you to modify every single request, adding/removing headers modifying get/post parameters, acting like a reverse proxy and much more. I just can't imagine developing API's without it. I've been using it for years. And ... its free.

Thanks for the suggestion, kraz. I used Fiddler on a different project a number of years ago and had forgotten all about it - I'll need to get familiar with it again!