We have do have a comparison benchmark. The older system we hope to replace is running on the same box in parallel. So we have essentially elikinated any factors that could bias the old system byt running the two in parallel on the same box
On Sun, Mar 8, 2009 at 3:06 PM, Daniel <[email protected]> wrote: > > It would be handy to have a low level performance test to perform on > the server setup. > > There are several bottlenecks that can be identified. That's all from > kernel issues, apache configurations (as discussed), mysql > configurations, symfony version, symfony configurations, application > code, ui code, internet connection speed, web browser speed and so on. > > It would be interesting to achive some kind of enviroment test for the > setup. I believe it would be quite hard to test all the mentioned > parts in once. But what could be tested is the setup of apache, mysql > and symfony as the "platform" from which almost all symfonians start > their development. To have these parts tested trough a performance > testing symfony application we could all achieve a sandbox that > doesn't have any unnecessary bottlenecks. The rest of the total > experience is more up to the developer due to the numerous ways to > work with Symfony. > > Any ideas? > > > /Daniel > > > On Mar 8, 11:27 am, 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 -~----------~----~----~----~------~----~------~--~---
