Development

#2202 ([PATCH] Better scalability with caching and different key generation.)

You must first sign up to be able to contribute.

Ticket #2202 (new enhancement)

Opened 1 year ago

Last modified 1 year ago

[PATCH] Better scalability with caching and different key generation.

Reported by: haakeyar Assigned to: francois
Priority: minor Milestone:
Component: sfUJSPlugin Version: 1.0.6
Keywords: Cc:
Qualification:

Description

Improved scalability by using the cache instead of the user session to save the UJS. http://groups.google.com/group/symfony-devs/browse_thread/thread/7ea169195e35d7e3/daf3ef362f410e27?lnk=gst&q=sfUJSPlugin&rnum=1#daf3ef362f410e27 (I'm sorry for my terrible writing in that post.)

The UJS key is an md5 of the UJS, so you can have user-specific data in the UJS without setting it to static (but if there is sensitive data in it, it should be set to static). This also makes long lifetimes possible, both on the server, on a proxy server and on the client.

Some of the internals of the plugin have been modified to simplify it. (Well, I guess there are more lines of code now than before, but...). The main part of the plugin is the sfUJS singleton.*

Unfortunately I don't have any unit tests for the sfUJS class. I know I should have, and I'm sorry. Maybe I can write someone later, but things are a bit hectic nowadays, so I don't have the time to do it right now. (There where no unit tests like that in the original version either. There were some, but those tested the helpers themselves, partly on the client side. They are still there and they still pass.) There is also the possibility that you hate my implementation, and then there would be no point in using time on the unit tests.

Since I am doing these changes for my own project too, I've removed the sfPJSPlugin dependency. I probably shouldn't have done so, or at least I should have added it to another ticket instead, but there is really no need for it and I don't understand why you are using it. Isn't it just adding another layer of complexity? If you really want to keep it, I could find the changes that I did to remove it and undo them, but is it really necessary? It is possible that I am missing something, and if that's the case, I'm sorry and I will add it back in again.

I've done some changes to the readme-file where I explain the added configuration options. English is my second language and I'm not really good at it, so its probably terrible and my changes probably has to be rewritten. :)

The plugin will probably not work in symfony 1.1, because of the refactored cache system, but porting it to 1.1 would probably be fairly easy.

I've added the extra files and folders to package.xml, but I haven't done any other changes to it.

*I'm not sure that a singleton is the best solution here. Maybe a factory would be better (or maybe not), but it looks like there has to be done changes deeper into symfony to add another element to its factory (I have to admit that I haven't looked too closely at it, so I might be wrong). Anyway, this can easily be changed. There are only a couple of calls to sfUJS::getInstance().

Attachments

sfUJSPluginPatch.patch (52.9 kB) - added by haakeyar on 09/08/07 01:41:24.
sfUJSPluginPatch.2.patch (52.9 kB) - added by haakeyar on 09/08/07 12:10:20.
Fixed a typo in my changes to the readme file.

Change History

09/08/07 01:41:24 changed by haakeyar

  • attachment sfUJSPluginPatch.patch added.

09/08/07 10:32:58 changed by francois

The sfPJSPlugin should be included into the symfony 1.1 core, in a way that makes caching easier. Besides, as you said, cache refactoring in 1.1 would make this plugin easier, too. In its current state, the UJS plugin is not very satisfactory, and I think we really need the features of sf1.1 to make it usable at a large scale. I'll have a look at your patch, but I'll probably wait until 1.1 is released to update the plugin.

Thanks anyway, that's an interesting approach.

09/08/07 12:10:20 changed by haakeyar

  • attachment sfUJSPluginPatch.2.patch added.

Fixed a typo in my changes to the readme file.

09/09/07 12:59:58 changed by haakeyar

  • qualification set to Unreviewed.

I personally think it would work out fine in 1.0.* too, and I am going to use it in a project I'm working on which uses syfony 1.0.*. It is of course entirely up to you if you want to wait, but it would be nice to be able to use the "official" version of the plugin and not a modified one.

With some help from sfSuperCache, it could probably get even more scalable. The url will need to end with .js, not .ujs. To avoid redirecting the other javascripts to symfony, the RewriteCond? for the plugin in .htaccess would need to be changed to something like (I haven't tested it yet): 

RewriteCond %{REQUEST_URI} !UJS/script/key.\.js$

And the rewrite rule (in config.php) would be changed to use .js instead of .ujs.The server should also be set up to serve the UJS from the super cache with the right cache headers.

As I said, I haven't tested this yet, and I don't have the time to do it right now, but I'll do it some time in the future.

What do you think about this approach?

Another thing I was thinking about is the strength a md5 hash. How (un)likely is it that it will generate the same key for two different UJSs? Is md5 enough or would sha-256 or something like that be better?