Skip site navigation (1) Skip section navigation (2)

Re: scalability issues on win32

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org,PostgreSQL Win32 port list <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: scalability issues on win32
Date: 2004-11-23 02:26:05
Message-ID: 200411230226.iAN2Q6i25020@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers-win32pgsql-performance
This was an intersting Win32/linux comparison. I expected Linux to scale
better, but I was surprised how poorly XP scaled.  It reinforces our
perception that Win32 is for low traffic servers.

---------------------------------------------------------------------------

Merlin Moncure wrote:
> Following is the promised writeup in performance related issues
> comparing win32 with linux x86 and linux x86-64.  Unfortunately, the 64
> bit portion of the test is not yet completed and won't be for a bit.
> However there are some telling things about the win32/linux comparison.
> If you are considering deploying postgres in a win32 environment read
> on...
>  
> First a description of the client app:
> Our company develops an ERP/CRM written in cobol which we are porting to
> run on PostgreSQL.  Part of this porting effort was development of an
> ISAM 'driver' for our app to allow it to store/fetch data from the
> database in place of a traditional file system, which is complete.
> 
> For those of you unfamiliar with COBOL/ISAM, applications written with
> it have a 'one record at a time' mentality, such the application tends
> to spam the server with queries of the select * from t where k = k1
> variety.  Our driver creates stored procedures as necessary and uses
> ExecParams wherever possible to cut down on server CPU time, which is a
> precious resource in our case.  Over time we plan to gradually redeploy
> our application logic to make better use of the sql server's server side
> power.  Our application is very rarely i/o bound because we will make
> sure our server has enough memory so that the data will be rarely, if
> ever, *not* run from the cache.
> 
> A good benchmark of our application performance is the time it takes to
> read the entire bill of materials for a product.  This is a recursive
> read of about 2500 records in the typical case (2408 in the test case).
> 
> Test platform:
> Pentium 4 3.06 GHz/HT
> 10k SATA Raptor
> 1Gb memory
> Windows XP Pro SP2/Redhat Fedora 3 (64 bit results coming soon)
> 
> BOM traversal for product ***** (1 user): 
> win32: runtime: 3.34 sec  avg cpu load: 60%
> redhat: runtime: 3.46 sec  avg cpu load: 20%
> 
> Well, win32 wins this test.  There is some variability in the results
> meaning for a single user scenario there is basically no difference
> between win32 and linux in execution time.  However the cpu load is much
> lower for linux which spells problems for win32 with multiple users:
> 
> BOM traversal for product ***** (6 users):
> win32: runtime (each): 7.29 sec  avg cpu load: 100%
> redhat: runtime (each): 4.56 sec  avg cpu load: 90%
> 
> Here, the win32 problems with cpu load start to manifest.  The cpu meter
> stays pegged at 100% while the redhat hand around 90%.  The difference
> in times is telling.
> 
> The third and final test is what I call the query 'surprise' factor, IOW
> surprise! your query takes forever!  The test involves a combination of
> the previous test with a query with a couple of joins that returns about
> 15k records.  On both redhat/win32, the query takes about .35 seconds to
> execute on a unloaded server...remember that figure.
> 
> 
> 
> Item List generation while 6 clients generating BOM for multiple
> products:
> Redhat: 2.5 seconds
> Win32: 155 seconds (!)
> 
> Here the win32 server is showing real problems.  Also, the query
> execution time is really variable, in some cases not returning until the
> 6 workhorse processes completed their tasks.  The linux server by
> contrast ran slower but never ran over 4 seconds after multiple runs.
> 
> Also, on the purely subjective side, the linux server 'feels' faster and
> considerably more responsive under load, even under much higher load.
> 
> Comments/Suggestions?
> 
> Merlin
> 
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-performance by date

Next:From: Josh BerkusDate: 2004-11-23 06:00:41
Subject: Re: Data type to use for primary key
Previous:From: Bruce MomjianDate: 2004-11-23 02:18:05
Subject: Re: memcached and PostgreSQL

pgsql-hackers-win32 by date

Next:From: Tony and Bryn ReinaDate: 2004-11-23 09:20:54
Subject: Re: Beta5 libpq Build broken with MS .NET 2003
Previous:From: Pierre-Frédéric CaillaudDate: 2004-11-22 23:15:26
Subject: Re: scalability issues on win32

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group