Hmm, it depends on your infrastructure. If you have one small web server with web and db server on one machine, and lots of traffic, with a high query count per page, then your db server will get backed up and it will be slow.
I have had sites once upon a time with very high query counts, 50-100, but they were all very clean straightforward queries, not many joins. So it wasn't too bad, we just had to split out the web and db server. I have also heard of a few other projects built with symfony + propel where they had to let the query count slip and get close to 100 queries per page, because with propel it is often easier to make multiple queries and do more work in php. With my current project, I am using doctrine, and most of my pages have 10 queries per page max. I am sure that might grow a little as we flesh some things out, but I am pretty happy with my numbers right now. I don't really know what is considered "good". You can get by with high query counts, but you just have to have the servers to support it. - Jon Oriol Mercadé wrote: > Great example, thanks! > > what do you think about the theoricall maximum tolerable number of > queryes per request? > > On 5/14/07, *Jonathan H. Wage* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > I think it should be stored in the instance of the user for each > request, rather than in the session. In large sites with lots of > users, > the memory usage for sessions could grow to be too large. Since each > request has only one instant of the sfUser class then you can > store the > guardUser, permissions, etc. all in that instance of the user, and > making multiple calls to the getGuardUser() will result in only one > query always for each request. > > This approach is kind of a middle ground between saving memory and > lowering the number of database queries. > > You can see how I did it in this function.. > http://jwage.pastebin.co.uk/14446 > > - Jon > > Oriol Mercadé wrote: > > Hello group, I have a dilema... > > > > I've seen that sfGuard pluggin, makes a query each time you call > > hasCredential() [when it is logged and it is not superadmin] > > I've seen also that everyTime that getGuardUser() is called, it > also > > leads to a query... > > > > Do you think it is a good idea to store the sfguard user object in > > session? i know it is an object and therefore it is not recommended > > but, it is an object with little information and it causes one > query > > per request when the user is validated in the system, > > > > I have the credentials already stored in the session, and if I > update > > a credential of a user in the bd i refresh the information in the > > session too, so merging credential in session and sfGuardUser in > > session may avoid one query to the bd in each request. > > > > What do you think? > > > > > > An other more philosophical question is... what number of db > queries > > do you think should not be done? > > I know that a request that generates N queries where N is the number > > of iterations of something is not tolerable, but what about 3 > queries > > per request? and 5? 10? > > what does your experience in production enviorements say? > > thank you very much in advance! > > > > -- > > - Oriol Mercadé Figueras > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
