In using JSON Server on bobdylan.com, we noticed two performance boosting tweaks:

1) Use json_encode() if it's available. (This produced a decent speedup.)
2) Use GZIP encoding if the client supports it (This gave us a GIANT performance boost.)

I need to re-roll the code into a patch, but #2 helped speed up the site a GREAT deal. I'll try to send it along in a week or so.

CommentFileSizeAuthor
#8 json_server.module.patch561 bytesjeffmace
#6 gzip.patch908 byteskarlshea
#4 json_server_gzip_performance.patch2.7 KBSteven Merrill

Comments

Steven Merrill’s picture

Steven Merrill commented

My reasoning for using json_encode() if available is as a speed boost (since it's baked-in,) and also by virtue of the fact that HTML escaping does not seem to be needed in drupal_to_js() any more - see http://drupal.org/node/222578#comment-773458.

andremolnar’s picture

andremolnar commented

Furthermore the escaping done results in invalid json being returned. I'll be happy to review your patch when it lands. Internally we've already made a similar change in some of our own json generation (unrelated to our services)

kehan’s picture

kehan commented

subscribing

Steven Merrill’s picture

Steven Merrill commented
Status: Active » Needs review
StatusFileSize
new json_server_gzip_performance.patch2.7 KB

Hey - look - a patch!

It's against CVS HEAD as of today. It will use json_encode if available, and GZIP compression if the client supports it. This helped boost performance quite a bit on BobDylan.com.

Enjoy!

karlshea’s picture

karlshea
he/him
Primary language English
Location Minneapolis 🇺🇸
commented
Version: 5.x-1.0 » 6.x-2.0-alpha1

It looks like this patch, or parts of it, made it into 2.0-alpha1?

There seems to be an issue with the gzip encoding part at the very end:

$size = strlen($contents);
$contents = gzcompress($contents, 9);
$contents = substr($contents, 0, $size);

I see that there are lots of comments on the gzcompress page on php.net discussing removing the crc at the end, and string lengths, etc. But the result of these three lines are that this goes in:

{"#error":false,"#data":{"foo":"bar"}}

and this comes out in the browser:

{"#error":false,"#data":{"foo":"bar

I double-checked this in Wireshark to make sure it wasn't just a browser issue, and it's getting cut off there after decompression as well.

If I remove the substring stuff and just send the gzcompress output to the browser, it gets uncompressed correctly in Firefox 3.6 on OS X at least. I'm not sure it's worth keeping in gzip compression if it's not going to work everywhere.

karlshea’s picture

karlshea
he/him
Primary language English
Location Minneapolis 🇺🇸
commented
StatusFileSize
new gzip.patch908 bytes

I'm attaching a patch that seems to fix the issue, containing some code ported from some of the gzcompress manual page's comments. This adds the correct bytes for crc and size to the end of the gzipped string, and seems to fix the issue of characters being stripped from the end of the string.

evanbarter’s picture

evanbarter commented
Status: Needs review » Reviewed & tested by the community

+1 for #6.

I noticed the malformed response in my browser but didn't think much of it. It wasn't until I started hitting the server in a mobile client I'm developing where it started causing all kinds of issues. Patch in #6 cleared these up.

jeffmace’s picture

jeffmace commented
StatusFileSize
new json_server.module.patch561 bytes

It looks like the problem is actually just because of the overhead of gzip on short strings. Some of the examples on the gzcompress page will only use gzcompress if the text is longer than 2048 characters. The attached patch does the same for json_server.module file and solved the issue for me without the overhead of more string concatenation.