Hey guys, i could do with some advice.
== the problem ==
In the java version, the features are all parsed and their javascript
content is loaded into memory. This works on the java side, and gives
the opportunity to cajol the entire content in one fell swoop, so that
works great.
Now on the PHP side of things things are a bit difference since PHP
works in a process-per-request type situation, so parsing the entire
features structure each request is non-doable, would make any semi
decent performance impossible to achieve, so instead i process the
features once and cache the entire resulting structure in cache, thats
about twice as fast as processing the features structure each request,
so it's survivable.
Survivable but far from optimal, it's a lot of information to read
from cache, and a lot of memory consumed (since every process has it's
own instance, it adds up), so that puts a good bit of pressure on the
server's IO.
To add some measurability to this, on a quad core @ 3ghz workstation
this gets me about 420 pages a second with apache bench.
== the solution ? ==
The main problem is the overhead of loading all the features
javascript each request, this consumes tons of memory and takes loads
of IO, so the overly obvious solution is to not do this anymore :)
So what would work is that i make all javascript external (<script
src="...">), generate script tags for each feature (and it's
dependencies) and modify the javascript handler (/gadgets/js) to only
output the javascript for the requested feature.
There are a few possible downsides i can identify though:
More requests, one per feature, however with an expiration data in the
far far future and a cache busting version param, this should be
negligible.. besides the amount of bandwidth used would go down
tremendously (a few small kb for a gadget instead of 180kb or so
because of all the inline javascript), so the combined browser side
caching of savings on bandwidth / time to transfer all this info ...
should actually have a positive effect right?
The second risk is that it could add some perceived latency since the
gadgets.config.init() and the onLoad handlers can't be called until
the document has completed, which includes handling the javascript
files, and whatever external resources the gadget includes.. this is
probably the biggest problem of this solution.
And finally, it would make cajoling impossible probably ... but that
doesn't concern me so much right now since we don't have a mechanism
for php shindig to do that anyhow :)
With that 'small' modification, the pages/second shoots up to 630, a
very significant increased, and that's with just a few hacks and not a
proper implementation of this option.
So the performance gains seem significant enough to consider this,
both in server load, pages/second and bandwidth saved.. however as
mentioned, there's a few risks involved too.
What do you all reckon would be the right solution here? Hope i can
get your opinions on what would be the better choice here since I'm a
bit torn between the two.
-- Chris
