Re: Server Databases Clash
От | Rod Taylor |
---|---|
Тема | Re: Server Databases Clash |
Дата | |
Msg-id | 008401c1c126$ebf710c0$8001a8c0@jester обсуждение исходный текст |
Ответ на | Server Databases Clash (Michael Tiemann <tiemann@redhat.com>) |
Список | pgsql-hackers |
> MySQL's great performance was due mostly to our use of an in-memory query > results cache that is new in MySQL 4.0.1. When we tested without this cache, > MySQL's performance fell by two-thirds. > > Anyway, this confirms an earlier message suggesting that for web servers that > have relatively constant queries, query caching can be a Big Deal. I'd be willing to bet that they would have been around 15 to 20% faster if their JSP code did the caching as there is no protocol or transfer overhead. For that matter, if they were to have used static webpages with no JSP code (updating those as needed) they probably could have been several orders of magnitude higher in their serving speed. If the information in the database is truely that consistent, it makes the most sense to go with the last option as you don't want the overhead of PHP, JSP, ASP and friends either. Afterall, why waste all that time generating the same HTML pages time and time again. The problem really has nothing to do with the database. PHP may wish to (and I think there is a project) add caching of a generated page for common request variables to avoid generation of the page entirely. High volume 'dynamic' websites often use this method when they expect a low number of changes. Slashdot is a good example. Static frontpage and main page of chat rooms, but once you go in a couple of levels it's generated on the fly due to high level of change compared to requests for the information.
В списке pgsql-hackers по дате отправления: