On Feb 4, 2008 4:34 PM, Thierry <thierryschellenb...@gmail.com> wrote:
> Would like to hear some of the opinions. > I'm considering giving it a spin...
I've played with it a bit, it looks very nice and efficient. The admin generator is by far the most advanced I've had played with, bundled ORM is really cool, generic views are really clever, etc.
What i did not like so much is URL handling (regex based, no reflexion) and the template engine syntax (but it's also very serious and flexible). Matter of taste.
I'd love doing a real project with it, that's to me the only way to see what it really worthes. The only problem we got here in France is that there's not much Python devs here... Hard to sell.
++
-- Nicolas Perriault http://www.clever-age.com Clever Age - conseil en architecture technique GSM: +33 6 60 92 08 67 Tél: +33 1 53 34 66 10
1 no debug toolbar 2 finding python developers is hard. 3 documentation is hard to locate, although the email list is very active 4 No javascript/AJAX integration, which isn't necessarily a bad thing 5 Also I don’t appear to be able to grasp a nice clean directory structure in the apps ive tried, it just seems a tad messy, but the django devs i worked with in a symfony project said the same about symfony, they couldn't cope with more than 10 files :)
On Behalf Of Nicolas Perriault Sent: 04 February 2008 16:04 To: symfony-users@googlegroups.com Subject: [symfony-users] Re: Django
On Feb 4, 2008 4:34 PM, Thierry <thierryschellenb...@gmail.com> wrote:
> Would like to hear some of the opinions. > I'm considering giving it a spin...
I've played with it a bit, it looks very nice and efficient. The admin generator is by far the most advanced I've had played with, bundled ORM is really cool, generic views are really clever, etc.
What i did not like so much is URL handling (regex based, no reflexion) and the template engine syntax (but it's also very serious and flexible). Matter of taste.
I'd love doing a real project with it, that's to me the only way to see what it really worthes. The only problem we got here in France is that there's not much Python devs here... Hard to sell.
++
-- Nicolas Perriault http://www.clever-age.com Clever Age - conseil en architecture technique GSM: +33 6 60 92 08 67 Tél: +33 1 53 34 66 10
Oh well, worst informed argument I've heard yet about Django, from what I've seen and used its good, just needs to mature a little and maybe rethink the physical file structure a bit.
Made me laugh all the way though, the RoR article that is :)
Mat wrote: > 5 Also I don’t appear to be able to grasp a nice clean directory structure > in the apps ive tried, it just seems a tad messy, but the django devs i > worked with in a symfony project said the same about symfony, they > couldn't > cope with more than 10 files :)
Yes, the first time I used it I had the same criticism, but I quickly found that the regex url mapping gave me extremely easy ways to create logical filesystem structures that made sense for my application.
Django is very easy to use, and I even really like the template syntax (especially the 'extends' directive - very cool. That having been said, one of the first things we did on our last django project was replace the template engine with Genshi). The main things I found lacking were:
* it is a little too dependent on its ORM - you have to go out of your way to break out of the database model, especially on the admin side. This makes sense for your everyday content-based kinds of sites, not so much when you are integrating with external systems.
* it lacks the 'component' idea that symfony has -- ie. each controller (uhh... i mean.. _view_) normally has to contain all the logic for an entire page, and there's no obvious way to split the page up into reusable functional elements.
Anyway, those points aside, Django is great, and I'm sure I'll be using it again when the right project comes along.
> -----Original Message----- > From: symfony-users@googlegroups.com > [mailto:symfony-users@googlegroups.com] > On Behalf Of Nicolas Perriault > Sent: 04 February 2008 16:04 > To: symfony-users@googlegroups.com > Subject: [symfony-users] Re: Django
> On Feb 4, 2008 4:34 PM, Thierry <thierryschellenb...@gmail.com> wrote:
>> Would like to hear some of the opinions. >> I'm considering giving it a spin...
> I've played with it a bit, it looks very nice and efficient. The admin > generator is by far the most advanced I've had played with, bundled > ORM is really cool, generic views are really clever, etc.
> What i did not like so much is URL handling (regex based, no > reflexion) and the template engine syntax (but it's also very serious > and flexible). Matter of taste.
> I'd love doing a real project with it, that's to me the only way to > see what it really worthes. The only problem we got here in France is > that there's not much Python devs here... Hard to sell.
> ++
> -- > Nicolas Perriault http://www.clever-age.com > Clever Age - conseil en architecture technique > GSM: +33 6 60 92 08 67 Tél: +33 1 53 34 66 10
Django appears to be a MVC framework, but you call the Controller the
"view", and the View the "template". How come you don't use the
standard names?
Well, the standard names are debatable.
In our interpretation of MVC, the "view" describes the data that gets
presented to the user. It's not necessarily how the data looks, but
which data is presented. The view describes which data you see, not
how you see it. It's a subtle distinction.
So, in our case, a "view" is the Python callback function for a
particular URL, because that callback function describes which data is
presented.
Furthermore, it's sensible to separate content from presentation --
which is where templates come in. In Django, a "view" describes which
data is presented, but a view normally delegates to a template, which
describes how the data is presented.
Where does the "controller" fit in, then? In Django's case, it's
probably the framework itself: the machinery that sends a request to
the appropriate view, according to the Django URL configuration.
If you're hungry for acronyms, you might say that Django is a "MTV"
framework -- that is, "model", "template", and "view." That breakdown
makes much more sense.
At the end of the day, of course, it comes down to getting stuff done.
And, regardless of how things are named, Django gets stuff done in a
way that's most logical to us.
Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names?
Well, the standard names are debatable.
In our interpretation of MVC, the "view" describes the data that gets presented to the user. It's not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It's a subtle distinction.
So, in our case, a "view" is the Python callback function for a particular URL, because that callback function describes which data is presented.
Furthermore, it's sensible to separate content from presentation -- which is where templates come in. In Django, a "view" describes which data is presented, but a view normally delegates to a template, which describes how the data is presented.
Where does the "controller" fit in, then? In Django's case, it's probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.
If you're hungry for acronyms, you might say that Django is a "MTV" framework -- that is, "model", "template", and "view." That breakdown makes much more sense.
At the end of the day, of course, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that's most logical to us.
After hearing about sf2.0 and then reading the django docs... I put 2
and 2 together. I'm actually really excited about sf2 now. I think
the flexibility (I'm assuming) it'll afford will be a huge sell for
some development teams.
As to the main question. I've been coding a lot of django in the last
few weeks and I do miss a lot of symfony stuff like the debug toolbar,
and sf's templating style, but the more I delve into it, I find decent
enough strategies for accomplishing the same thing. I do miss the
flexibility of specifying js/css dynamically... it's possible, but
it's entirely different from how i'm used to doing it.
If it makes sense, a debug toolbar can probably be written for django
as a piece of middleware. I'm just not quite at that level to create
such a thing at the moment...
On Feb 4, 8:27 am, Fabien POTENCIER <fabien.potenc...@symfony-
> After hearing about sf2.0 and then reading the django docs... I put 2
> and 2 together. I'm actually really excited about sf2 now. I think
> the flexibility (I'm assuming) it'll afford will be a huge sell for
> some development teams.
> As to the main question. I've been coding a lot of django in the last
> few weeks and I do miss a lot of symfony stuff like the debug toolbar,
> and sf's templating style, but the more I delve into it, I find decent
> enough strategies for accomplishing the same thing. I do miss the
> flexibility of specifying js/css dynamically... it's possible, but
> it's entirely different from how i'm used to doing it.
> If it makes sense, a debug toolbar can probably be written for django
> as a piece of middleware. I'm just not quite at that level to create
> such a thing at the moment...
> On Feb 4, 8:27 am, Fabien POTENCIER <fabien.potenc...@symfony-
> project.com> wrote:
> > Django is just awesome. I think it's the best python framework... and
> > some features of symfony 2.0 are inspired by Django ;-)
No, read the comments. As usual with Slashdot it's an alarmist popularist news story to get a response.
In short, the Python team are doing what's needed to move the language forward, and what I believe the PHP team should have done between PHP4 and PHP5, in order to prevent the crazy situation of still having to write PHP4-compatible sites today in 2008 (yes I do have to do it for some clients).
On Feb 6, 3:54 pm, Dave Dash <d...@davedash.com> wrote: > After hearing about sf2.0 and then reading the django docs... I put 2 > and 2 together. I'm actually really excited about sf2 now. I think > the flexibility (I'm assuming) it'll afford will be a huge sell for > some development teams.
> As to the main question. I've been coding a lot of django in the last > few weeks and I do miss a lot of symfony stuff like the debug toolbar, > and sf's templating style, but the more I delve into it, I find decent > enough strategies for accomplishing the same thing. I do miss the > flexibility of specifying js/css dynamically... it's possible, but > it's entirely different from how i'm used to doing it.
> If it makes sense, a debug toolbar can probably be written for django > as a piece of middleware. I'm just not quite at that level to create > such a thing at the moment...
> On Feb 4, 8:27 am, Fabien POTENCIER <fabien.potenc...@symfony-
> project.com> wrote: > > Django is just awesome. I think it's the best python framework... and > > some features of symfony 2.0 are inspired by Django ;-)
I've played with the CVS version of Django... interesting. Some fresh
air. I really liked the way they used the term "perfectionist" in
several places, and how they believe no functionality should ever be
duplicated, and how they're willing to automate stuff. I've gone
through the tutorial, and I'm now reading the book. One thing:
"template inheritance" seems backward. It essentially does what
Symfony does with layouts and component slots, where the former
"includes" the latter. I really like the way Symfony distinguishes
what to put in actions and what to put to YAML files. For example,
return sfView::SUCCESS. Very geeky. No need to hardcode a template
name in the action: that part is delegated to *.yml configs. Overall,
Django looks more automation-ready than Symfony 1.0, and I don't mean
its admin/admin generator. It's really for programmers that respect
the DRY principle, essentially encompassing everything I was forced to
do myself in Symfony 1.0... I really hope 1.1 will be getting closer
to perfection.
Peter Bowyer wrote: > In short, the Python team are doing what's needed to move the > language forward, and what I believe the PHP team should have done > between PHP4 and PHP5, in order to prevent the crazy situation of > still having to write PHP4-compatible sites today in 2008 (yes I do > have to do it for some clients).
Couldn't agree more, I'm up for HUGE BC breaks in PHP between, for exmaple, PHP5 and PHP6 if it means improvements to the language itself.
Trying to support the mistakes from the past forever is a silly idea IMO.
I'd quite like to increase the speed of my website (facebook app), as we are experiencing what I class as high loads (18k hits/hour), and the strain on load times is starting to tell, and its only getting worse (10-20% growth daily).
I've got a quick question, I would typically use the debug toolbar to work out the number of database queries per page, however as this is javascript based it isn't available to me...(due to facebook format). Is there any other quick and easy way to tell the number of db queries per page so I can optimise these. My instinct was to look through the logs however I thought I would ask here first if there was an easier solution to getting at the debug toolbar information without needing javascript. I'd also quite like to look at the profiler information as well, however I suspect this isn't the issue and my lack of join's in propel statements is.
Also any other tips for easy optimisations? The plan was to install a php optimiser as well, and also to try and disable some of the symfony code which isn't needed, (like the helpers we don't use).
Hi, installing a PHP accelerator brings a huge benefit. Besides that I would recommend that you turn on the logging in mysql (assuming that you use it:-))
Let it log all queries that are slow and those not using indices. If you are bold you can even log all queries that are going to the db.
Then make a tail -f onto the logfile and let users use the app. It helps to resolve the top issues very quickly (assuming that you either know which queries could come from what action/page, or your app is not very large so you can find out from the query which line of code resulted in that query)
grbounce-3gx0ZwUAAACbeXgKRGBnB9JmBRJWwY06=fabian.lange=web...@googlegroups.c om [mailto:grbounce-3gx0ZwUAAACbeXgKRGBnB9JmBRJWwY06=fabian.lange=web.de@googl e groups.com] On Behalf Of Mat Sent: Freitag, 8. Februar 2008 13:50 To: symfony-users@googlegroups.com Subject: [symfony-users] DB connections without Debug toolbar
Hey all,
I'd quite like to increase the speed of my website (facebook app), as we are experiencing what I class as high loads (18k hits/hour), and the strain on load times is starting to tell, and its only getting worse (10-20% growth daily).
I've got a quick question, I would typically use the debug toolbar to work out the number of database queries per page, however as this is javascript based it isn't available to me...(due to facebook format). Is there any other quick and easy way to tell the number of db queries per page so I can optimise these. My instinct was to look through the logs however I thought I would ask here first if there was an easier solution to getting at the debug toolbar information without needing javascript. I'd also quite like to look at the profiler information as well, however I suspect this isn't the issue and my lack of join's in propel statements is.
Also any other tips for easy optimisations? The plan was to install a php optimiser as well, and also to try and disable some of the symfony code which isn't needed, (like the helpers we don't use).
Can you recommend any specific PHP accelerator? Are any easier to setup than others, and do any perform any better than other, open source is always preferred :)
I'm going to look into the mysql logging it isn't something I've tried before, so this could be interesting....
The App only has about 2-3 key pages, so tracking down slow queries isn't an issue, this is why we didn't optimise it from the start, as we always felt we could track it down onsite quickly after we had traffic, just didn't expect this much traffic this quickly....It is also why I have still to setup caching.....:$... now is probably the time to do it.
On Behalf Of Fabian Lange Sent: 08 February 2008 13:28 To: symfony-users@googlegroups.com Subject: [symfony-users] Re: DB connections without Debug toolbar
Hi, installing a PHP accelerator brings a huge benefit. Besides that I would recommend that you turn on the logging in mysql (assuming that you use it:-))
Let it log all queries that are slow and those not using indices. If you are bold you can even log all queries that are going to the db.
Then make a tail -f onto the logfile and let users use the app. It helps to resolve the top issues very quickly (assuming that you either know which queries could come from what action/page, or your app is not very large so you can find out from the query which line of code resulted in that query)
.: Fabian
-----Original Message----- From: grbounce-3gx0ZwUAAACbeXgKRGBnB9JmBRJWwY06=fabian.lange=web...@googlegroups.c om [mailto:grbounce-3gx0ZwUAAACbeXgKRGBnB9JmBRJWwY06=fabian.lange=web.de@googl e groups.com] On Behalf Of Mat Sent: Freitag, 8. Februar 2008 13:50 To: symfony-users@googlegroups.com Subject: [symfony-users] DB connections without Debug toolbar
Hey all,
I'd quite like to increase the speed of my website (facebook app), as we are experiencing what I class as high loads (18k hits/hour), and the strain on load times is starting to tell, and its only getting worse (10-20% growth daily).
I've got a quick question, I would typically use the debug toolbar to work out the number of database queries per page, however as this is javascript based it isn't available to me...(due to facebook format). Is there any other quick and easy way to tell the number of db queries per page so I can optimise these. My instinct was to look through the logs however I thought I would ask here first if there was an easier solution to getting at the debug toolbar information without needing javascript. I'd also quite like to look at the profiler information as well, however I suspect this isn't the issue and my lack of join's in propel statements is.
Also any other tips for easy optimisations? The plan was to install a php optimiser as well, and also to try and disable some of the symfony code which isn't needed, (like the helpers we don't use).
I saw a tenfold increase in the speed of my Symfony apps by enabling
eaccelerator. I my company we use this on several servers and I
haven't had any problems with it. It just sits there in the background
and makes everything MUCH faster.
I did some benchmarking of uncached pages vs cached pages. If I cached
away all components accessing the database the speed increased from 70
requests per second to 300. With the amount of hits you have even a
cache with a very short expiry time would help significantly.
In my benchmarking I didn't see much performance improvement by
disabling parts of Symfony. The two most significant speed increases
were from enabling eaccelerator and from caching away database
requests.
On Feb 8, 3:50 pm, "Mat" <gro...@wakari.co.uk> wrote:
> Can you recommend any specific PHP accelerator? Are any easier to setup than
> others, and do any perform any better than other, open source is always
> preferred :)
> I'm going to look into the mysql logging it isn't something I've tried
> before, so this could be interesting....
> The App only has about 2-3 key pages, so tracking down slow queries isn't an
> issue, this is why we didn't optimise it from the start, as we always felt
> we could track it down onsite quickly after we had traffic, just didn't
> expect this much traffic this quickly....It is also why I have still to
> setup caching.....:$... now is probably the time to do it.
> On Behalf Of Fabian Lange
> Sent: 08 February 2008 13:28
> To: symfony-users@googlegroups.com
> Subject: [symfony-users] Re: DB connections without Debug toolbar
> Hi,
> installing a PHP accelerator brings a huge benefit.
> Besides that I would recommend that you turn on the logging in mysql
> (assuming that you use it:-))
> Let it log all queries that are slow and those not using indices.
> If you are bold you can even log all queries that are going to the db.
> Then make a tail -f onto the logfile and let users use the app. It helps to
> resolve the top issues very quickly (assuming that you either know which
> queries could come from what action/page, or your app is not very large so
> you can find out from the query which line of code resulted in that query)
> .: Fabian
> -----Original Message-----
> From:
> grbounce-3gx0ZwUAAACbeXgKRGBnB9JmBRJWwY06=fabian.lange=web...@googlegroups.c
> om
> [mailto:grbounce-3gx0ZwUAAACbeXgKRGBnB9JmBRJWwY06=fabian.lange=web.de@googl e
> groups.com] On Behalf Of Mat
> Sent: Freitag, 8. Februar 2008 13:50
> To: symfony-users@googlegroups.com
> Subject: [symfony-users] DB connections without Debug toolbar
> Hey all,
> I'd quite like to increase the speed of my website (facebook app), as we are
> experiencing what I class as high loads (18k hits/hour), and the strain on
> load times is starting to tell, and its only getting worse (10-20% growth
> daily).
> I've got a quick question, I would typically use the debug toolbar to work
> out the number of database queries per page, however as this is javascript
> based it isn't available to me...(due to facebook format). Is there any
> other quick and easy way to tell the number of db queries per page so I can
> optimise these. My instinct was to look through the logs however I thought I
> would ask here first if there was an easier solution to getting at the debug
> toolbar information without needing javascript. I'd also quite like to look
> at the profiler information as well, however I suspect this isn't the issue
> and my lack of join's in propel statements is.
> Also any other tips for easy optimisations? The plan was to install a php
> optimiser as well, and also to try and disable some of the symfony code
> which isn't needed, (like the helpers we don't use).
I'm actually giving eaccelerator a go as we speak, just setting up php.ini now...
As for caching, I've not got very much experience in this, but I suspect that in this app it might not do that much good. I've got memcached up on the server, and was looking at caching the db requests and maybe some function calls/pages.
The app is essentially a game where every request effects the next. I suppose we could cache each user's stats and but it would only be valid for 1-2 page calls at best...Would anyone think this is still worth caching? For such a short period? I'm probably going to give it a go anyways and see what performance increase I can get, but any hints/advice would be greatly welcomed :)
On Behalf Of Daniel Staver Sent: 08 February 2008 17:27 To: symfony users Subject: [symfony-users] Re: DB connections without Debug toolbar
I saw a tenfold increase in the speed of my Symfony apps by enabling eaccelerator. I my company we use this on several servers and I haven't had any problems with it. It just sits there in the background and makes everything MUCH faster.
I did some benchmarking of uncached pages vs cached pages. If I cached away all components accessing the database the speed increased from 70 requests per second to 300. With the amount of hits you have even a cache with a very short expiry time would help significantly.
In my benchmarking I didn't see much performance improvement by disabling parts of Symfony. The two most significant speed increases were from enabling eaccelerator and from caching away database requests.
On Feb 8, 3:50 pm, "Mat" <gro...@wakari.co.uk> wrote: > Thanks, we are indeed Mysql based,
> Can you recommend any specific PHP accelerator? Are any easier to setup than > others, and do any perform any better than other, open source is always > preferred :)
> I'm going to look into the mysql logging it isn't something I've tried > before, so this could be interesting....
> The App only has about 2-3 key pages, so tracking down slow queries isn't an > issue, this is why we didn't optimise it from the start, as we always felt > we could track it down onsite quickly after we had traffic, just didn't > expect this much traffic this quickly....It is also why I have still to > setup caching.....:$... now is probably the time to do it.
> On Behalf Of Fabian Lange > Sent: 08 February 2008 13:28 > To: symfony-users@googlegroups.com > Subject: [symfony-users] Re: DB connections without Debug toolbar
> Hi, > installing a PHP accelerator brings a huge benefit. > Besides that I would recommend that you turn on the logging in mysql > (assuming that you use it:-))
> Let it log all queries that are slow and those not using indices. > If you are bold you can even log all queries that are going to the db.
> Then make a tail -f onto the logfile and let users use the app. It helps to > resolve the top issues very quickly (assuming that you either know which > queries could come from what action/page, or your app is not very large so > you can find out from the query which line of code resulted in that query)
> .: Fabian
> -----Original Message----- > From:
grbounce-3gx0ZwUAAACbeXgKRGBnB9JmBRJWwY06=fabian.lange=web...@googlegroups.c > om
[mailto:grbounce-3gx0ZwUAAACbeXgKRGBnB9JmBRJWwY06=fabian.lange=web.de@googl e > groups.com] On Behalf Of Mat > Sent: Freitag, 8. Februar 2008 13:50 > To: symfony-users@googlegroups.com > Subject: [symfony-users] DB connections without Debug toolbar
> Hey all,
> I'd quite like to increase the speed of my website (facebook app), as we are > experiencing what I class as high loads (18k hits/hour), and the strain on > load times is starting to tell, and its only getting worse (10-20% growth > daily).
> I've got a quick question, I would typically use the debug toolbar to work > out the number of database queries per page, however as this is javascript > based it isn't available to me...(due to facebook format). Is there any > other quick and easy way to tell the number of db queries per page so I can > optimise these. My instinct was to look through the logs however I thought I > would ask here first if there was an easier solution to getting at the debug > toolbar information without needing javascript. I'd also quite like to look > at the profiler information as well, however I suspect this isn't the issue > and my lack of join's in propel statements is.
> Also any other tips for easy optimisations? The plan was to install a php > optimiser as well, and also to try and disable some of the symfony code > which isn't needed, (like the helpers we don't use).
> I'd quite like to increase the speed of my website (facebook app), > as we are > experiencing what I class as high loads (18k hits/hour), and the > strain on > load times is starting to tell, and its only getting worse (10-20% > growth > daily).
> I've got a quick question, I would typically use the debug toolbar > to work > out the number of database queries per page, however as this is > javascript > based it isn't available to me...(due to facebook format). Is there > any > other quick and easy way to tell the number of db queries per page > so I can > optimise these. My instinct was to look through the logs however I > thought I > would ask here first if there was an easier solution to getting at > the debug > toolbar information without needing javascript. I'd also quite like > to look > at the profiler information as well, however I suspect this isn't > the issue > and my lack of join's in propel statements is.
> Also any other tips for easy optimisations? The plan was to install > a php > optimiser as well, and also to try and disable some of the symfony > code > which isn't needed, (like the helpers we don't use).
Balaji Srinivasan wrote: > Hi Mat > I have modified the SF Web Toolbar so that it works with Facebook. > Get in touch with me if you want a copy of it. > Balaji
> On Feb 8, 2008, at 4:50 AM, Mat wrote:
>> Hey all,
>> I'd quite like to increase the speed of my website (facebook app), >> as we are >> experiencing what I class as high loads (18k hits/hour), and the >> strain on >> load times is starting to tell, and its only getting worse (10-20% >> growth >> daily).
>> I've got a quick question, I would typically use the debug toolbar >> to work >> out the number of database queries per page, however as this is >> javascript >> based it isn't available to me...(due to facebook format). Is there >> any >> other quick and easy way to tell the number of db queries per page >> so I can >> optimise these. My instinct was to look through the logs however I >> thought I >> would ask here first if there was an easier solution to getting at >> the debug >> toolbar information without needing javascript. I'd also quite like >> to look >> at the profiler information as well, however I suspect this isn't >> the issue >> and my lack of join's in propel statements is.
>> Also any other tips for easy optimisations? The plan was to install >> a php >> optimiser as well, and also to try and disable some of the symfony >> code >> which isn't needed, (like the helpers we don't use).
Sure. I havent worked with symfony plugins before so it might take me a bit of time for it. Let me play with the plugin over the weekend and Ill let you know how soon I can get it in. Thanks Balaji
> If you have done so, can you contribute it to > sfFacebookPlatformPlugin?
> Kiril
> Balaji Srinivasan wrote: >> Hi Mat >> I have modified the SF Web Toolbar so that it works with Facebook. >> Get in touch with me if you want a copy of it. >> Balaji
>> On Feb 8, 2008, at 4:50 AM, Mat wrote:
>>> Hey all,
>>> I'd quite like to increase the speed of my website (facebook app), >>> as we are >>> experiencing what I class as high loads (18k hits/hour), and the >>> strain on >>> load times is starting to tell, and its only getting worse (10-20% >>> growth >>> daily).
>>> I've got a quick question, I would typically use the debug toolbar >>> to work >>> out the number of database queries per page, however as this is >>> javascript >>> based it isn't available to me...(due to facebook format). Is there >>> any >>> other quick and easy way to tell the number of db queries per page >>> so I can >>> optimise these. My instinct was to look through the logs however I >>> thought I >>> would ask here first if there was an easier solution to getting at >>> the debug >>> toolbar information without needing javascript. I'd also quite like >>> to look >>> at the profiler information as well, however I suspect this isn't >>> the issue >>> and my lack of join's in propel statements is.
>>> Also any other tips for easy optimisations? The plan was to install >>> a php >>> optimiser as well, and also to try and disable some of the symfony >>> code >>> which isn't needed, (like the helpers we don't use).
|
