I hope this is the right forum to post in, apologies if it isn’t.
We’re wrangling with improving the length of time ckeditor.php takes to download on our VBulletin driven forum site. We’ve made some significant improvements on the server side - ardwiring the XML inside the php file, rather than the default method vbulletin uses of building the XML file on the fly and we’ve seen great improvements in FF, Chrome and Safari, where times are now down to 120-200ms. eg:
Almost 2 seconds of processing/downloading is a huge amount of time for a small file that doesn’t do very much!
We’re thinking that it may how the IE ajax object operates. And it may not be the fault of the ckeditor.php file, but rather the fact that it is the first ajax requested… and that IE essentially sits there until all ajax components on the page are ready before it starts to do anything with ckeditor.
Do you see the same slowness when you use a regular IE8 location (without dynatrace)? It’s possible that the profiling is adding some overhead that just happens to be hitting at the wrong time.
I don’t have dynatrace on the laptop I’m using right now but I can take a closer look at the captured trace file on Monday if that’s the case.
Many thanks for your response. I re-ran WPT with the same settings, with IE8 but without dynatrace and there is certainly an improvement. Ckeditor is now in the 1200-1500 range as opposed to the 2 seconds plus we were experiencing, so you’re right it does look like the dynatrace profiling is having an impact, but it’s still way longer (more than a second longer) than the equivalent FF and Chrome times…
I appreciate some time has passed since this post, but I wonder if you had any further thoughts on it. We’re still stumped
could it be it’s how the IE ajax object operates. And it may not be the fault of the ckeditor.php file, but rather the fact that it is the first ajax requested…
I’m pretty certain it’s not an Ajax thing, it’s much more likely to be javascript execution that just happens to be running at the same time as the download so it makes the download look like it takes a lot longer.
I’d try re-running the script with Chrome and timeline capture enabled to see if that exposes anything interesting but the best bet may be to just start blocking code (or commenting out functions) in a staging/dev environmet to see where the expensive operations are.
