From the Blog
While AJAX has its place, it’s good to learn when not to use it.
We discovered with our Intranet project significant speed penalties introduced by loading a lot of dynamic content in via AJAX at the same time. It’s very easy to get carried away and try load everything in with jQuery, but on an initial page draw this is clearly a Bad Thing:
Take our Intranet portal as an example. It consists of 9 widgets, each of which has fully dynamic content. After the portal is initially constructed by the server, loaded by the client, and jQuery has initialised, each Widget then goes and fetches its own content. This resulted in an average 35 seconds until the page was fully ready. Clearly this in unacceptable.
Going back and re-working the widgets so that they “pre-populate” the data server side reduced this time to 5 seconds. Subsequent updates are then performed by jQuery AJAX calls so the user experience is unaffected.
A lot of this is due to locking – only two connections can be made to a web server at once from a single client, so an application that generates many AJAX requests will end up having request queued. Also all those requests going back and forth from the server generate a lot of overhead, not to mention that once all the data has finally been received by the client poor jQuery has to do a lot of work!
So we learned the hard way: be careful how you use AJAX!
Another week, and Misa-misa (AKA Vixen) has modified Kameko for BiteSizedJapan. She’s looking cuter each version!
We use Persits excellent ASPEmail, ASPJpeg and ASPUpload components, however we found another gotcha with the installation of these components under Windows Server 2003 x64 with IIS running in 32bit mode (see previous post).
Despite uninstalling our previous x64 bit versions of these components, we had issues with the components simply doing “nothing” after a subsequent server restart. Loading pages that made use of any of these server side components simply returned blank values, without any sort of error.
After a bit of digging around, it seems that our uninstalling of the x64 components leaves some stuff in the registry, and in turn causes some sort of conflict with the 32bit versions. So the trick is:
- In RegEdit, Find the key HKEY_LOCAL_MACHINE\SOFTWARE\Persits Software\ and remove it
- Uninstall all the components, even if they are 32bit
- Reboot the server
- Reinstall the components
- Reboot the server again
So far everything seems to be working again for us.
After struggling for a week trying to get various 64bit components to run under IIS6 on our new servers, I was banging my head against the wall. Why oh why doesn’t Microsoft make these things easy?
So with a deep breath I tried tackling running IIS in 32bit mode again… and discovered a “gotcha” that probably caused our issues the first time around.
It appears when you run the “fix” that turns 64bit IIS into 32bit, Windows isn’t smart enough to realise “yes I really did mean 32bit” and promptly breaks IIS completely – resulting in the ever so popular “Service not available” message for all your precocious web sites. Why? Well, it seems this is due to the .NET framework running in 64bit, regardless of the fix. Thankfully (!!!!) you can install .NET from the command line with 32bit-ness in place…
- To enable 32bit IIS mode run: cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs set w3svc/AppPools/Enable32bitAppOnWin64 1
- Restart IIS (at this point IIS will probably stop serving sites)
- Reinstall the .NET framework in 32bit mode: C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i -enable
- Restart your server
Very frustrating. We’ve yet to full test this, but we applied the change on our test server and all our sites are working. Tomorrow we’ll add some 32bit components and see what happens…
In our infinite wisdom, for the BiteSizedJapan project it was decided that writing a Publishing system from scratch would ensure a much better fit for the magazine than trying to hack an existing content management system.
Let me say this up front: Content Managers are not easy to write!
Thankfully the pain is somewhat mitigated thanks to TinyMCE and a lot of jQuery.
I’m not quite sure whoever decided this branding would be a good idea or not hadn’t been at the Christmas booze a bit early this year themselves:
Seriously?
BiteSizedJapan features “bento” boxes filled with “bites” of Japanese culture. While researching sites, I came across inspiration from down under, in the form of Love Bento! Gorgeous layout, simple but effective.
Another late night with team BiteSizedJapan, but we now have some of our other community projects running for the magazine. Over at Flickr we have a brand new stream, we have a dedicated blog for the magazine over at blog.bitesizedjapan.com (a bit rough and ready) and of course we’re on Twitter (@bitesizejapan) now too. If that’s not enough, we’ve also setup a Youtube account for good measure.
blog.bitesizedjapan banner