I 've read that one before. But I wonder... Is it the reading that is bad about .htaccess? I would think that it is the scanning process that slows down the request. When the usage of .htaccess is allowed, apache will check on every request if a .htaccess is present. I you request an image, like www.domain.com/images/picture.jpg apache will look for a .htaccess in the folder 'images'. If no such file is found, it will try to locate one in your web root.
Disallowing the usage of .htaccess in your httpd.conf will eliminate this overhead as Lee suggested. This is actually a question as I am not sure of the statement above. Anybody got any experience with system administration? James On Mar 7, 8:42 pm, Lee Bolding <[email protected]> wrote: > I couldn't agree more. > > Did I already mention moving the .htaccess rules into the apache > httpd.conf? that way it doesn't get read on every single request... > > On 7 Mar 2009, at 15:00, James Cauwelier wrote: > > > > > Hi, > > > There are some good ideas in this post, but they don't have a lot of > > value if you haven 't identified your bottelenecks first. Did you run > > this website on an isolated VPS or dedicated server? In that case, > > you could look at the processes taking the most resources. If your > > database is in fact a big consumer, then caching could be really > > helpful. But bear in mind that cache has to be created and if you 're > > not satisfied with the uncached performance, then you should fix that. > > > Are you using an ORM? If yes, check if you 're not running too many > > queries per request? Too many queries could be fixed by joining with > > reference tables. Sometimes you should use doSelectJoinX() instead of > > doSelect () with Propel. > > > What 's your database schema like? Do you use MySQL MyIsam or innoDb > > tables? If you are using MyIsam and you have a lot of traffic, then > > know that MyIsam uses table level locking. If you update a row in > > your table, all other statements have to wait until the update/create > > is finished. Identify your bottleneck and test in a production like > > environment. Isolating one query is not really representative. Run > > some benchmarks and simulate real usage. > > > Read 'Adding your own timer' on > >http://www.symfony-project.org/book/1_2/16-Application-Management-Too... > > Accumulate your time with every database query, to see how much time > > is spent by the database. Also look at the timings in you query log > > from the debug bar. Do they seem correct compared to your own > > findings when isolating a query? > > > A lot of RAM would indeed be nice, but pixelmeister is only suggesting > > this because they seem to make extensive use of memcached. If you 're > > not memcaching, then more than 2GB of RAM won 't do you much good. > > (unless RAM is a bottleneck for some other reason, like heavy CRON > > jobs. Again, identify your bottlenecks) > > > Marijn 's question is a very good one: "Are we talking about perceived > > performance or actual performance?" (pssssttt ... Identify your > > bottleneck) > > > James > > > On 7 mrt, 14:33, pixelmeister <[email protected]> wrote: > >> Hi, > > >> i also had this kind of problems on a big site (120 Mysql Tables) > >> with > >> aprox. 100000 page views a Day. > > >> The best way to get the site running fast is: > > >> Use caching with memcached (sfMemCached class) > >> We had a lot of problems with the standard file cache and > >> SqliteCache. > > >> Use xcache or an other bytecode cachesystem like eAccelerator > > >> Improve your mysql indexes manually. I couldn't find a proper way > >> to do it > >> with the schema.yml files. > > >> Give your Server a lot, really a lot of RAM :-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
