Hi.
Noticed the routing has had performance changes in 1.3 which is great.
The cache is now recommended to be off but we have a severe impact on
our system if we do that.
Would like to open a discussion re: possible improvement if this is
ok.
We have lots of routes - our app is built around admin generator and
therefore sfPropelRouteCollection. The routing performance changes in
1.3 appear to be when loading routes, but the performance penalty for
our app is when matching a route i.e. url_for().
e.g. below is output from xhprof
Current Function
sfPatternRouting::getRouteThatMatchesParameters 56 0.1% 1,360,102
82.9%
Exclusive Metrics for Current Function 173,620 12.8%
Parent function
sfPatternRouting::generate 56 100.0% 1,360,102 100.0%
Child functions
sfObjectRoute::matchesParameters 22,455 48.5% 1,115,255 82.0%
sfRoute::setDefaultParameters 23,148 50.0% 50,048 3.7%
sfRoute::matchesParameters 693 1.5% 21,179 1.6%
Bit difficult to read sorry, but basically
sfPatternRouting::getRouteThatMatchesParameters() is called 56 times
(for the 56 links we have) but it takes 1.3 seconds to execute this
code. This is on athlon x2 4600+.
The problem seems to be that sfObjectRoute::matchesParameters() is
called 22,455 times taking 1.1 seconds of the total time.
OK, so if we enable the file cache we get good speeds again, however
the problem is the amount of data in this cache. Because we have so
many routes and are using admin gen, we hit this problem:
route is
supplier:
class: sfPropelRouteCollection
options:
model: Supplier
module: supplier
prefix_path: supplier
with_wildcard_routes: true
if we have 1000 suppliers, we get an entry in the routing cache for
each of these urls. Also, in the layout of the pages we have menu
links. e.g. menu/admin, menu/stock. (there's approx 100 of these)
The problem is, because the url is supplier/1/edit, supplier/2/edit,
supplier/3/edit the context when generating the cache key is different
because the uri changes. This means for every supplier, we also have
all the menu links stored in the cache for that instance of supplier.
So in the cache we have 1,000*100 = 100,000 entries in the cache - and
that is for one module (we currently have 64 admin generated modules +
30 odd non-admin gen). e.g. our routing cache contains this:
["parse_/supplier/1/edit_2ed71130b65896bc589714492c3cc85c"]=>
array(3) {
...
["parse_/supplier/2/edit_8179119534b860346bafa3dedb2bad53"]=>
array(3) {
...
["parse_/supplier/3/edit_118c94f897cfc7ae68a124e8dd692f4a"]=>
array(3) {
and
["generate_logout_e4ed1a882c44f3cf31e7ed18e8686b65_516891fa3258fae54e8eaed2b2727dcb"]
=>
string(7) "/logout"
...
["generate_logout_e4ed1a882c44f3cf31e7ed18e8686b65_54e6d2c24d12203af92e3f785f1a567d"]
=>
string(7) "/logout"
...
["generate_logout_e4ed1a882c44f3cf31e7ed18e8686b65_2ed71130b65896bc589714492c3cc85c"]
=>
string(7) "/logout"
i.e. a application "logout" link for each of the 3 supplier pages I
have just visited - the last md5 is different for each one (different
context)
Other concern is the size of the data will get so large that the
overhead of read/unserialize()/serialize()/write() will cause a large
performance penalty.
Specifying each route by name is an option, though not one I wish to
go down if possible - plus I don't think it will correct the 'size of
data' issue.
Possible solution (though I do not understand the routing enough) but
is it possible to not generate the cache key on the parameter values,
but just on the parameter keys? so, md5(serialize(array_keys
($params))) instead. Or can the value of a param determine a different
route? Similarly, is it possible for the context to not include the
uri, or use the internal uri instead of real one e.g. supplier/:id/
edit - that way the context would be the same regardless of id.
Hope this makes sense. I'm sure it's not an easy one to resolve...
Thanks,
Andy.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
