Re: [PERFORM] Drupal and PostgreSQL - performance issues?
От | Mikkel Høgh |
---|---|
Тема | Re: [PERFORM] Drupal and PostgreSQL - performance issues? |
Дата | |
Msg-id | 06DDE07E-3CF9-4B3E-8536-7C164BAB8FC6@hoegh.org обсуждение исходный текст |
Ответ на | Re: [PERFORM] Drupal and PostgreSQL - performance issues? (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [PERFORM] Drupal and PostgreSQL - performance issues?
|
Список | pgsql-general |
Alright, my benchmarks might have been a bit naïve. When it comes to hardware, my webserver is a SunFire X2100 with an Opteron 1210 Dual Core and 4 GB DDR2 RAM, running 64-bit Ubuntu Linux Server 8.04 LTS. When it comes to the resource usage section of my postgresql.conf, the only thing that are not commented out are: shared_buffers = 24MB max_fsm_pages = 153600 I freely admit that the reason I haven't messed with these values is that I have next to no clue what the different things do and how they affect performance, so perhaps an apology is in order. As Scott wrote, "Without a realistic test scenario and with no connection pooling and with no performance tuning, I don't think you should make any decisions right now about which is faster". My apologies. -- Kind regards, Mikkel Høgh <mikkel@hoegh.org> On 13/10/2008, at 06.54, Stephen Frost wrote: > * Mikkel Høgh (mikkel@hoegh.org) wrote: >> I have been testing it a bit performance-wise, and the numbers are >> worrying. In my test, MySQL (using InnoDB) had a 40% lead in >> performance, but I'm unsure whether this is indicative for PostgreSQL >> performance in general or perhaps a misconfiguration on my part. > > The comments left on your blog would probably be a good first step, if > you're not doing them already.. Connection pooling could definitely > help if you're not already doing it. Drupal's MySQL-isms don't help > things either, of course. > > Also, you don't post anything about the PostgreSQL config, nor the > hardware it's running on. The default PostgreSQL config usually isn't > appropriate for decent hardware and that could be a contributing > factor > here. It would also be useful to make sure you've analyze'd your > tables > and didn't just do a fresh load w/o any statistics having been > gathered. > > We run Drupal on PostgreSQL for an internal site and it works > reasonably > well. We havn't had any performance problems but it's not a terribly > large site either. The issues we've had tend to come from > PostgreSQL's > somewhat less-than-supported status with Drupal. > > I've been meaning to look into Drupal's PG support to see about > improving it. Perhaps this winter I'll get a chance to. > > Thanks, > > Stephen
Вложения
В списке pgsql-general по дате отправления: