Unix or Windows

[Genie06]

Hi Guys

Just wondered what your opinions are on whether to go for a Unix or Windows database server. Our system is basically a Windows only client side, mainly record reads (up to maybe 10gb in size eventaully - say after 3 years, spread of 5 - 7 different databases), although a lot the records are "archive" records and are never really read on a daily basis. There have been internal discussions before about the issue of
-B in Unix allowing more memory (64 bit), but i arent 100% convinced by that as my tests have shown Windows always performs better (certainly for our system anyway!). Any thoughts / comments much appreciated!

Thanks

 

[TomBascom]

Use windows for clients and UNIX for Progress servers.

While it is possible to make a small Windows server that is as fast and as reliable as a similarly sized UNIX server it isn't likely to stay that way.

UNIX is easier to write scripts for and to manage in a "lights out" manner. It is common for UNIX servers to run for years without anyone doing anything to them. It might be possible but it is certainly unusual for the same thing to happen with a windows box.

OTOH... if you don't have any in-house UNIX skills but you do have windows skills and it is a relatively small system then Windows might be a tolerable choice.

IMHO.

 

[Genie06]

Hi Tom

Thanks, one thing to note though is that all of our processes are ran on the windows client, the unix boxes do nothing except server the databases. the boxes we fit a pretty hefty machines (8 processors, 16gb RAM etc etc). in this scenario would you still recommend using unix as opposed to windows?

 

[TomBascom]

I'm not sure that I understand your comment about remote clients -- that shouldn't matter. Both servers are going to have to deal with remote connections. Even if they were self-service clients both types of server can manage.

I'm assuming that we are comparing running UNIX (more likely Linux) vs running Windows on the same hardware.

In which case I still prefer UNIX for all of the reasons that I mentioned. One other reason is that, on the same hardware, Linux requires fewer resources because you aren't forced to run a GUI In particular UNIX will have more free RAM available and does a better job of managing it than windows does. IMHO.

As far as pure Progress server performance goes it shouldn't really matter. Since the later v9 releases the two platforms are more or less equal on identical hardware. (Prior to that Windows servers were substantially slower.)

If, OTOH, we are comparing beefy Windows boxes vs. anemic Unix boxes then there may, perhaps, be an argument that Windows is going to do better.

Given the same hardware and the general equality of performance the decision comes down to ease of management. And IMHO UNIX wins that handily. But I'm a UNIX guy

 

[joey.jeremiah]

Hi Tom

Thanks, one thing to note though is that all of our processes are ran on the windows client, the unix boxes do nothing except server the databases. the boxes we fit a pretty hefty machines (8 processors, 16gb RAM etc etc). in this scenario would you still recommend using unix as opposed to windows?

Hello Genie,

Sorry for jumping in so late.

But I really hope you'll not be using remote connections to the database (from a client or agent) and I hope remote clients will be using an AppServer.

If you're using a remote database connection you might as well be using super computer and you'll still be getting lousy overall performance, you'll be getting far better performance using a self serving connection.

It'll be, relatively, simple to put together an example of the performance difference.

 

[Genie06]

Hi

Unfortunately that is the case, and we dont use appserver (i dont work in development!) when you say "self-service" client, what do you mean? We basically have a now progress 9.1x or OE10 installed on the DB box (enterprise) and then client networking on each client PC (or citrix box if using citrix) then the clients directly access database! thats why i think the windows servers are faster becuase they are better suited to handling that type of request (or am i wrong!). Thanks for the reply!

 

[joey.jeremiah]

self-service means the client access the database directly through shared memory not network connection.

for a self-service connection to be possible the database and client need to be running on the same machine and not use remote database connection (simply no -H and -S database connection startup parameters)

the progress remote connection is notoriously slow particularly for query focused operations, 20x or more slower then a self-service connection. imo just a flat out bug in the implementation. it was probably some "wizard" idea to put it together this way.

if you can get the database and clients on the same machine, possibly, using citrix (not sure if that is the case) that would definitely be a big strong point, as much as the raid setup or many other very important issues.

btw, what's the application ? product or home grown ? if it is home grown why not use an appserver ? how many expected clients ? ... tell us more.

 

[Genie06]

Hi!

We do use some connections in shared memory, these are mainly "batch queue" connections which run non-interactive. The application is a mainly read system (very few writes), holding data about tenancies and properties (in general a housing system), clients on site varies from between 20 - 650 - big variation i know! The appserver idea is a good one but i cant seem them ever using it. Does shared memory work if the databases are on a mapped drive (For example S:\DB\LIVE\DB1.DB?

thanks for the help!

 

[joey.jeremiah]

Hi!

We do use some connections in shared memory, these are mainly "batch queue" connections which run non-interactive. The application is a mainly read system (very few writes), holding data about tenancies and properties (in general a housing system), clients on site varies from between 20 - 650 - big variation i know! The appserver idea is a good one but i cant seem them ever using it. Does shared memory work if the databases are on a mapped drive (For example S:\DB\LIVE\DB1.DB?

thanks for the help!

it's definitely an important factor if the application is more read then write intensive, progress 4gl stronger side is definitely, and focuses more on transactions then queries.

how about a simple example ? nothing speaks louder if you'll see the difference yourself, right ?.


i'm more of a developer then a system or dba guy, i'd like to think , i'm especially no where close to rock star dba's like Tom.

but in regards to mapped drives, i think, they're strongly recommended against because it's hard to tell if changes are being commited to disk (or maybe that's only or mostly for the bi), they're probably also performance related issues, which would probably be a huge performance bottleneck.

but mostly we're talking about where the broker, the processes and the client/s are running and not about the physical storage, because they'd need to share/access the same memory storage.


so the application is home grown ? i'm definitely not saying you're going to have to rebuild or modernize your application now but it's something to keep in mind, and it's not that complicated either.

another thing is that i'd also recommend trying peg.com you'll likely get alot more answers from more gurus to these type of questions.

 

[Genie06]

Hi!

Thanks for all of that, i will try to go back to the developers with some info. The simple queries (such as find first blah blah where blah = blah) run far quicker on windows than unix, but some of my colleagues say that the -B (buffer size) makes a massive difference on performance and i just wondered if that was the case becuase my own tests have shown it makes no difference!?!

Thanks again

 

[joey.jeremiah]

find first etc. and for each ... for a single table would run pretty quick and without a whole lot of difference in any setup, you'd even get acceptable performance on a WAN.

the problem and 20x performance difference starts with for each and queries for multiple tables.

i'll post a more thorough explanation about the 4gl remote connection implementation, hopefully, tomorrow.

and talk about a very simple example, for each or query that we can write together and for your database that will show the difference.

it's important for me to show you the difference between self and remote connection.

 

[Genie06]

that would be excellent!

thanks very much for your help!

 

[tamhas]

No, you shouldn't ever put the database on a simple share and it wouldn't provide a performance boost even if you did.

Appserver would be good because it could put query resolution onto the same box as the database.

If the read activity is most queries, then sticking with ABL is appropriate, but if you are also doing a lot of reporting, then you might consider a SQL reporting tool like Actuate or even Crystal because the SQL engine has some query features not yet available in ABL (Grrrrr) like no-index scans and a query optimizer.

-B is definitely a major impact, but only one of many parameters you should be looking at.

If the performance comparison you are coming up with where Windows is on top and you are using Workgroup, then you should ask whether the Unix is an dual core or dual CPU box because you might be seeing the SMP bug (extensively addressed on PEG).

You might get a better quality of answer if you posted either on the Database Administration forum here or dba@peg.com where the DBA's hang out ... although you did manage to attract Tom's attention.

Tom has already said so, but I think that if you ask around in either of those forums that you would find the same answer, i.e., that across the board, the same hardware running Linux will outperform that hardware running Windows. And, it seems that most DBAs prefer having Unix's scripting ability to help make their job easier. I just wouldn't seriously consider a Windows server unless there was no Unix experience around and no willingness to acquire it. If you are putting these into customer sites, all the more reason to go with Unix because there is much more control and it is quite straightforward to create secure and easily managed environments in which the customer can manage the application using simple scripts. I generally have little IT expertise at my sites and they do just fine with my scripts and minimal training.

 

[TomBascom]

Hi!

Thanks for all of that, i will try to go back to the developers with some info. The simple queries (such as find first blah blah where blah = blah) run far quicker on windows than unix,

A simple query that returns one record (as FIND FIRST will) should be so fast as to be essentially unmeasurable. On either platform. So it is hard to imagine how you can decide that one or the other is faster. Or why you would care.

If you're seeing a difference then it seems likely that you are not comparing apples to apples.

but some of my colleagues say that the -B (buffer size) makes a massive difference on performance and i just wondered if that was the case becuase my own tests have shown it makes no difference!?!

Thanks again

Sounds like something is wrong with your tests

Big B should make a significant difference any time a substantial number of records is queried.

 

[TomBascom]

Tom has already said so, but I think that if you ask around in either of those forums that you would find the same answer, i.e., that across the board, the same hardware running Linux will outperform that hardware running Windows.

That was true for v8 and early v9 releases (prior to 9.1D).

Today I would expect them to be pretty much equal if they are both being competently run.

 

[TomBascom]

Hi
We basically have a now progress 9.1x or OE10 installed on the DB box (enterprise) and then client networking on each client PC (or citrix box if using citrix) then the clients directly access database! thats why i think the windows servers are faster becuase they are better suited to handling that type of request (or am i wrong!). Thanks for the reply!

It shouldn't matter.

If there is a difference it is not because one sort of server is better suited than the other to handle that type of request. It is much more likely that important parameters are misconfigured.

 

[tamhas]

Even if the potential of a Windows server "competently run" is close to equal, I would still put my bet on the Unix box because the Unix will consume fewer resources, leaving more for the application, and it it more straightforward to "competently run" a Unix box than a Windows box. Not that either is automatic, but for all of the Windows-trained people out there, not many of them seems to understand much, whereas it doesn't seem to be all that difficult to find pointers on kernel tuning.