Hi,
I checked your code and mine again; now i recall my main concern
regarding performance: i wanted to get rid of the regex matching on
the php side and move completely to our nginx side. Our setup is
basically 2 nginx servers in front of 18 servers running the sf code
using fastcgi (php-fpm to be more precise). As those nginx are quite
calm most of the time, i wanted to make them do this routing and
parameter matching as well. The php shouldn't have to do any routing
nor regex matching then.
Based on a route looking like this:
module1profile:
url: /moduleuno/:id
param: { module: module1, action: profile }
requirements: { id: \d+ }
I got the mod_rewrite rule:
RewriteRule ^moduleuno/(\d+)$ _cache_routing/module1profile.php?id=$1
[QSA,L]
In my case, i already extract the parameter "id" out of the url and i
should not need to call the method sfRoute::matchesUrl.
>From what i get from your code, it will only do that for one route;
the one you specify with the parameter "sf_route". It will not go
through all the routes and this is already good for performance i
think. But you will still need to extract the parameters...
And this also why i don't have a unique entry point. I should be able
to "hardcode" those parameters in it as the my file will be specific
to a route. On the side, i don't like those unique entry point as it
makes debugging/profiling difficult (everything appears as index.php)
and also it adds a complex routing logic to the php where it should be
lightweight. I like generating php files, everything should be defined
in xml files with some builders taking care of creating specialized
and simple php files but this is really out of topic :-)
I will keep playing with my plugin and nginx. I can help with the
nginx output formatter still, it will be very similar.
For your questions:
- the routing.yml is like 1100 lines so maybe 280 routes.
- we are using a mix of APC/memcache; the routing will be in APC
though.
- nginx can handle much more requests than apache. We replaced 4 high
loaded servers (running squid) by 2 (and just because we needed
redundancy, the load is minimal). Then php-fastcgi processes will be
requested much more than with apache. It is difficult to evaluate
because we changed our code to symfony at the same time that we
changed our setup; so we needed to double our php servers due to the
overhead of the framework (don't worry it is much better now). Overall
nginx simplified/improved a lot our setup and is definitely a solid
product for production.
I wrote a post last year about it if you are interested in nginx:
http://www.thenetcircle.com/2008/08/22/the-squid-is-dead-long-live-to-the-nginx/
Cheers,
Boby
On Oct 8, 3:28 am, Thomas Rabaix <[email protected]> wrote:
> Hello,
> Your feedbacks will be great to see performance impact !
>
> If you want to code the nginx output you are free to go ;) Ask to be a
> plugin's member, so you can commit changes to the plugin repository.
>
> I don't see the point to create a php file per module/action. Can you be
> more specific on this particular need ?
>
> Can you give me more input :
>
> - How many routes do you have in your application ?
> - What kind of caching mechanism are you using : xcache/APC/memcached (or
> a mix ?)
> - How fast is nginx compared with Apache/fastcgi ?
>
> Thanks !
>
> On Wed, Oct 7, 2009 at 8:06 PM, Arnaud Seilles
> <[email protected]>wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > I am a little new to the scene so i will do a short introduction; i am
> > a php developer for a quite popular German dating website. Since 1
> > year now, we run symfony to deliver content to 20,000 concurent users
> > at peak time. So we have a lot of performance problems that we try to
> > solve and routing is one as well.
>
> > Your solution is quite interesting; in fact i am working on something
> > very similar just this week as well and was going to publish it on our
> > company blog until one of my workmate points me to your post.
> > Basically i created a task to generate the rewrite rules in the
> > htaccess based on the routing config.
>
> > I am still in development, but i can see the difference so far:
> > - no unique frontend entry point; i generate a php file based on
> > index.php for each routing rule.
> > - focus on other webservers; we use nginx in prod, i just used apache
> > for debug. As they both accept PCRE rules, it shouldn't matter.
>
> > At the end, my rules looks more like:
> > RewriteRule ^moduleuno/(\d+)$ _cache_routing/module1profile.php?id=$1
> > [QSA,L]
>
> > I find it more elegant but i guess it is my own opinion :)
>
> > Anyway you seems more advanced (testing, factory...) , i guess i will
> > leave my plugin as it is. Still i am highly interested in using this
> > solution in production and with nginx. Do you have any plan for an
> > nginx output? If not i can take a shot at it.
>
> > Cheers,
>
> > Boby
>
> > On Oct 7, 4:42 pm, Thomas Rabaix <[email protected]> wrote:
> > > Hello,
> > > I have been working on an original concept with goal to speed up symfony
> > > routing management : write a mod_rewrite file from the routing.yml file
>
> > > Please read :
> >http://trac.symfony-project.org/browser/plugins/swOptimizeRoutesPlugi...
>
> > > The current implementation is very alpha,
>
> > > - sf_method requirement is not handled.
> > > - the plugin save 9Mb of memory on a 60Mb memory usage per request (I
> > > have php5.3 64bits)
> > > - the routing.yml.php is now 240Kb instead of 1Mb (400 routes)
> > > - routes are loaded on demand, so there is only 10-30 sfRoute instance
> > > per request
> > > - direct access to the route (so no php route matching)
>
> > > The only problem (and not the less...) is the server handle less request
> > > than the current implementation (sf1.2) ! It is not an issue with the
> > > mod_rewrite file, but with the current php implementation.
>
> > > For now, I have no time to profile the implementation, but if anyone has
> > an
> > > idea, please share it ;)
>
> > > --
> > > Thomas Rabaixhttp://rabaix.net
>
> --
> Thomas Rabaixhttp://rabaix.net
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
