Great, we are working using propel, but we are trying to maintain queries between 6 and 2, exceptionally 8. We use a lot of joins tough. Thank you again!
On 5/14/07, Jonathan H. Wage <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > > > > > > > > > > > > -- - 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 -~----------~----~----~----~------~----~------~--~---
