R
Rob Fitzpatrick
Guest
You will get the best client performance from having them connect self-service (shared memory). But as you note, if you make your database server into a terminal server, that brings its own risks and challenges. Such a configuration puts more load on the database server and takes OS resources away from the database, making it more challenging to tune. It means running Windows, with anti-malware software and other overhead. It may mean giving shell access to all of your users, if you are doing desktop virtualization. Personally, I prefer not to use Windows as a DB platform, though many of my clients choose it as it is more familiar for them to administer. As I said, out-of-the-box client/server performance may be much less than self-service. That said, you shouldn't be accepting the configuration defaults for client startup parameters or for client/server-related database broker startup parameters. With proper tuning of parameters like Mpb, Ma, Mi, Mm, prefetch*, etc., combined with use of jumbo ethernet frames, you may well be able to get client/server performance that is good enough for your needs. You ask about general performance-tuning recommendations. It is hard to say without really knowing anything about your environment or application. But in general terms: - use 64-bit OE (at least on the back end) - use the Enterprise RDBMS - ensure you have good storage hardware and sufficient RAM - leverage caching wherever you can, through appropriate settings for -B, -B2, -Bt, -tmpbsize, -Bp, -mmax, -bibufs, -aibufs, -omsize, -ecsize, etc., to minimize physical I/O - ensure your database has a modern structure (all application data in Type II areas, one object type per area, appropriate RPB/BPC settings) Performance is a big subject. It would be helpful to know more about your environment and any specific performance issues you have today. Also, the KB is a good resource (knowledgebase.progress.com). It has several articles about database performance, client/server performance, query tuning, etc.
Continue reading...
Continue reading...