Ticket #6524 (closed defect: fixed)

Opened 6 months ago

Last modified 6 months ago

wp-includes/js/tinymce/tiny_mce_config.php very slow

Reported by: Toolskyn Assigned to: anonymous
Priority: low Milestone: 2.5.1
Component: TinyMCE Version: 2.5
Severity: normal Keywords: has-patch
Cc:

Description

wp-includes/js/tinymce/tiny_mce_config.php gave problems in my installation. That file took almost 16 seconds to load.

After some debugging I found out that if I comment line 259:

header( 'Content-Length: ' . strlen($content) );

its loadtime was reduced extremely, back to a more normal value.

When I looked at the tiny_mce_config.php alone I could already see al content while it was still loading. So the browser was waiting for content while everything was already available. So it looks like the strlen($content) returns a value that is too large.

The browsers I used to test this were Firefox 3 beta 4, Safari 3.10 and Opera 9.23

Attachments

6524.patch (0.7 kB) - added by azaozz on 04/03/08 04:33:49.
6524.2.patch (0.6 kB) - added by azaozz on 04/08/08 01:16:46.
OK, removing content-length

Change History

04/02/08 06:59:19 changed by azaozz

Toolskyn, can you provide some information about the web server you're using and if it's a local install (localhost). Also could you download the cached file /wp-content/uploads/js-cache/tinymce_[long number].gz and compare its size with what's returned in the header for content length. Thanks.

04/02/08 19:15:21 changed by Toolskyn

I'm running an Ubuntu (gutsy) webserver (no localhost) with:

  • Apache/2.2.4
  • PHP/5.2.3 (- MySQL 5.0.45)
  • Size of tinymce_....js : 236,868 bytes
  • Size according to the header (using Firebug) : 236,868 octets

So that's the same. Still when I remove the Content-Length the loading-times are reduced to some normal value.

I looked at some other static files, and nothing goes wrong there. So I'm guessing it isn't my webserver config. I tried commenting the whole caching part of the file, and I noticed the page loading fast in that case.

04/03/08 04:33:15 changed by azaozz

  • keywords set to has-patch.

I couldn't reproduce it. Loading directly /wp-includes/js/tinymce/tiny_mce_config.php from a server with similar configuration averages at about 0.8 sec. with compression and server side caching disabled.

Also line 259 should run only once when TinyMCE's configuration is changed, after that the server side cache is saved and on the next load it should return header "HTTP/1.1 304 Not Modified" if caching in the browser is enabled.

Header "Content-length ..." is not essential. RFC 2616 lists it as "should use". It may help to speed things up, especially when there is high packet loss on the net.

On the other hand when TinyMCE is gzipped, the server sets header "Transfer-Encoding chunked" which ignores Content-length, so it's better to not send it at all in this case.

04/03/08 04:33:49 changed by azaozz

  • attachment 6524.patch added.

04/06/08 21:33:08 changed by matt

This patch is weird, if it's not required why not just stop using it, rather than add more conditionals.

04/08/08 01:16:46 changed by azaozz

  • attachment 6524.2.patch added.

OK, removing content-length

04/09/08 05:27:02 changed by azaozz

I think I found out why it was slowing down: the compressor was detecting zlib.output_compression enabled, so it wasn't compressing it and was sending Content-length of the uncompressed file.

However the file was later compressed in the buffer, so the length was incorrect. Disabling Content-length fixes it. The second patch is the right one.

04/09/08 19:02:13 changed by ryan

  • status changed from new to closed.
  • resolution set to fixed.

(In [7635]) Don't send content length for tinymce config. Props azaozz. fixes #6524 for trunk

04/09/08 19:02:47 changed by ryan

(In [7636]) Don't send content length for tinymce config. Props azaozz. fixes #6524 for 2.5