At the company I developed a symfony plugin to optimize the Propel queries and also the Propel hydrate method, improving even 5 times query speed and also memory usage.
The plugins supports joins and thanks to PHP features the plugin returns Propel objects populated with custom AS columns. We are thinking on release it on the following weeks so stay tuned :) Regards, Alvaro On Mar 8, 2009, at 10:20 PM, Gareth McCumskey wrote: > We have put numerous caching techniques into effect, from Cache- > Expires headers to compression of static files like js and html > files. Currently we use symfony 1.1 and Propel as the ORM. We have > identified the bottleneck generally as being the application > processing after the db queries have run to extract the data. > > The entire point of my question was to get some info on general tips > and tricks we can try out to see if anything helps or if perhaps we > have missed any obvious issues that may actually be the cause of the > slow performance we are getting. As it is I have gotten quite a few > and look forward to getting into the office tomorrow to try them > out. Anymore is greatly appreciated. > > Of course I am looking through the code to see if there is anyway we > can streamline it on that end, but every little bit helps. > > Gareth > > On Sun, Mar 8, 2009 at 12:27 PM, Crafty_Shadow <[email protected]> > wrote: > > Gareth, you didn't mention what version of symfony you were using, > also what ORM (if any). > The best course of optimization will depend on those. Also, as already > mentioned, caching is your best friend. > > On Mar 8, 9:43 am, Gareth McCumskey <[email protected]> wrote: > > Well, consider a single database table that looks something like > this: > > > > From_address > > to_address (possibly multiple addresses comma-seperated) > > headers > > spam_report > > subject > > > > And we would have millions of those records in the database. > Repeated > > entries, especially on to_address, means the data is hugely > redundant. By > > normalising we are turning a text search across millions of > records with > > redundant repeated data into a text search over a unique list, > then an > > integer search over primary key (which of course is indexed). > > > > On Sun, Mar 8, 2009 at 9:37 AM, Lawrence Krubner > <[email protected]>wrote: > > > > > > > > > On Mar 8, 3:26 am, Gareth McCumskey <[email protected]> wrote: > > > > We had a speed increase because we had a lot of text searches > in the old > > > > system, all going through text fields where the same values > were repeated > > > > over and over. Its therefore a lot faster to search a much > smaller table, > > > > where the text fields are unique, and find the value once, > then use an ID > > > > comparison, being much faster to match integers than text. > > > > > In sounds like you got a speed boost from doing intelligent > indexing. > > > What you are describing sounds more like indexing than > normalization, > > > at least to me. > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
