It’s nice to live experimental life, isn’t this whole world just experimental beta version, which hopefully will be revised to 1.0 version in sometime. Well, while waiting that, must do own experiments.
Like doing profiling: Photo Album (access rights, and concerning privacy laws apply, so beware)
I kicked in profiling into prototype, and not so surprisingly slowest things weren’t the framework, but my own code, which all related into handling of EXIF data for images. Basically there was two problems: (a) EXIF if data for every photo was read separately for every EXIF attribute access (ouch!), (b) Access to thumbnail cache had broken synchronization (accessed from multiple threads).
Just patched those, and throwed in also global SoftReference cache of parsed infos, to avoid constant reparsing, and it response time definitely improved. Not so surprising, however, since before fixes system was blocking most of time in table cell generation, trying to read that darn EXIF metadata.
Additional notice: I had also forget to add ”application/json” as compressable types in tomcat. It may or may not affect something, since there is anyway apache in front so, oh, well…
While here, I decided also upgrade tomcat 6 to version 7 (newer and better, blah-blah). After some effort of googling hidden magic parameters, from multiple different sources, I managed to get it more or less working. Better than old version? Well, hard to say, not much difference in reality.
Considering that outbound bandwidth is less than 1Mb/s, it works reasonably well (this disclaimer is mandatory, before anyone starts saying ”it’s slow…”).
Oh, yes, sorry that’s my private photo album, don’t go in there.
Update 26.2.2012
Naturally, doing asyncronous code is always tricky, and of course I had also issues due to not releasing background worker threads. So worker threads were never killed after client session expiring, thus server had memory leak, which gradually starts to slow it down. However, after doing those fixes, I clearly broke some syncronization logic, since now sometimes folder contents don’t show up (duh!).
Btw, technically I’ve now experimented with ICEpush vaadin addon to provide asyncronous logic. I would have tried ”Dont Push” but the hard reality is that relying into websockets isn’t yet feasible in this world. There is various reasons why, first being of course the fact that one cannot trust that such technology is either provided or enabled by client web browser.
Even if that condition is fullfilled, one cannot trust that it can work, due to greedy phone operators or their broken confgurations..
So trying to rely into existence of them may be bad idea. Of course, since all testing on web service will be (generally) done without 3G, and even if done with it, then most likely not involving all possible phone operators in the world, so it’s hard to know if service shall work in real life.
Based on this experience, I would consider having two web services, JSF (or such) based for low end devices and more advanced framework for fatter clients. I won’t however, start prototyping such dual logic on this sample, since I don’t have enough time. But rather if I would have had reasonable old web interface, it would have made great sense to keep that one alive, while introducing this new one. However, since old one was PHP experiment, I’m not desiring to put it back online (IMO, PHP is horrible language).
Oh yes, there also was the fact that Tomcat 7 doesn’t yet support really websockets. And I didn’t want to start playing with another java web server. When tomcat adds support for them, then I will start experimentation with them.