Past version 10, are any versions of openedge multithreaded?
- Thread starter kblackwel
- Start date
Rob Fitzpatrick
ProgressTalk.com Sponsor
What does IBM know about Progress, or about the application(s) that run on top of it in your environment?
What a database does will in large part be a function of what it is asked to do. If the application layer slams it with requests it will be active. If the app sits there idle, the database will be largely idle, whether it comprises one thread or a hundred.
In discussions like this it is important to ask good questions, and by that I mean to be precise and specific in terminology.
"Multi-threaded" refers to a process that spawns more than one thread. OpenEdge isn't a process, so this question requires more precision to be meaningful.
ABL servers and ABL/SQL brokers are implemented in _mprosrv. This process is single-threaded, though an online database may have one or many brokers, each of which may spawn many servers, each of which may service requests from many remote clients.
SQL servers spawned by _mprosrv are implemented in _sqlsrv2. This process is multi-threaded, spawning one thread per connection. Threads come and go as connections do.
4GL (ABL) clients are implemented in _progres. It is single-threaded.
AppServer and WebSpeed brokers are java processes, and so will be multi-threaded. They spawn agents which run ABL code and are implemented in _progres and thus single-threaded.
A typical Enterprise database will have a Before-Image Writer process, an After-Image Writer process, a Watchdog process, and several Asynchronous Page Writer processes. They are implemented in _mprshut. Each is single-threaded, but obviously as a collective there are multiple threads.
The dbtool utility is multi-threaded.
Binary dumps are multi-threaded. ASCII dumps are single-threaded, and binary dumps can be configured as such if desired, but again you can achieve multi-threading by running several at once, and the OS scheduler will spread the CPU load across many cores.
Several parts of the index rebuild are multi-threaded.
The upshot of all this is that a typical busy, client-rich database back end has many many threads doing various things at various times. Some threads will be active during client DB access, some will be busy during authentication and connection/disconnection, some just cycle on some interval and do various housekeeping tasks.
Is it "better" to have one monolithic process, or a few, that consolidate all of these functions and are multi-threaded? Will that make your life better or make your CPUs do more work than if you have many discrete single-threaded processes that you can stop and start individually? I doubt it. Either way, I have to believe that the big-brained architect types at Progress (and other DB vendors) who make these low-level architectural decisions have good reasons for their designs and have more informed opinions on the subject than the average user like me.
If it will make you happy to run nmon and see all of your cores spiked, run multiple multi-threaded binary dumps simultaneously. Or run a full index rebuild with your client params maxed out. Trust me, you'll be CPU-bound at least part of the time and you will be glad to have the 8 cores.
What a database does will in large part be a function of what it is asked to do. If the application layer slams it with requests it will be active. If the app sits there idle, the database will be largely idle, whether it comprises one thread or a hundred.
In discussions like this it is important to ask good questions, and by that I mean to be precise and specific in terminology.
"OpenEdge" is a brand name for a family of products and technologies, and each of those may encompass many different components running on different platforms and implemented in different languages. A partial list would include database server processes, both 4GL and SQL, helper processes, database utilities, 4GL and SQL clients, AppServer/WebSpeed brokers and agents, NameServers, various integration adapters, Admin Servers, etc. All of these and more fall under the OpenEdge banner.
"Multi-threaded" refers to a process that spawns more than one thread. OpenEdge isn't a process, so this question requires more precision to be meaningful.
The database isn't a process either. When you run an Enterprise database in multi-user mode and access it with many clients you will have many different processes running, on the database server and perhaps on other machines as well. It is worth looking at what they are and what they do.
ABL servers and ABL/SQL brokers are implemented in _mprosrv. This process is single-threaded, though an online database may have one or many brokers, each of which may spawn many servers, each of which may service requests from many remote clients.
SQL servers spawned by _mprosrv are implemented in _sqlsrv2. This process is multi-threaded, spawning one thread per connection. Threads come and go as connections do.
4GL (ABL) clients are implemented in _progres. It is single-threaded.
AppServer and WebSpeed brokers are java processes, and so will be multi-threaded. They spawn agents which run ABL code and are implemented in _progres and thus single-threaded.
A typical Enterprise database will have a Before-Image Writer process, an After-Image Writer process, a Watchdog process, and several Asynchronous Page Writer processes. They are implemented in _mprshut. Each is single-threaded, but obviously as a collective there are multiple threads.
The dbtool utility is multi-threaded.
Binary dumps are multi-threaded. ASCII dumps are single-threaded, and binary dumps can be configured as such if desired, but again you can achieve multi-threading by running several at once, and the OS scheduler will spread the CPU load across many cores.
Several parts of the index rebuild are multi-threaded.
The upshot of all this is that a typical busy, client-rich database back end has many many threads doing various things at various times. Some threads will be active during client DB access, some will be busy during authentication and connection/disconnection, some just cycle on some interval and do various housekeeping tasks.
Is it "better" to have one monolithic process, or a few, that consolidate all of these functions and are multi-threaded? Will that make your life better or make your CPUs do more work than if you have many discrete single-threaded processes that you can stop and start individually? I doubt it. Either way, I have to believe that the big-brained architect types at Progress (and other DB vendors) who make these low-level architectural decisions have good reasons for their designs and have more informed opinions on the subject than the average user like me.
If it will make you happy to run nmon and see all of your cores spiked, run multiple multi-threaded binary dumps simultaneously. Or run a full index rebuild with your client params maxed out. Trust me, you'll be CPU-bound at least part of the time and you will be glad to have the 8 cores.
TomBascom
Curmudgeon
As I mentioned yesterday -- SXE is a target rich tuning opportunity. You almost certainly have many, many unexploited options available to you which, if implemented, will result in a system that reaches its full potential.
Doing that requires a lot more than casting about for a silver bullet like multi-threading. It requires working through the startup parameters and configuration options of the database, the clients, the application itself, AIX and all of the other parts of this puzzle. If you are in a hurry you might want to consider engaging a consultant who has some experience with SXE. I happen to know several
Doing that requires a lot more than casting about for a silver bullet like multi-threading. It requires working through the startup parameters and configuration options of the database, the clients, the application itself, AIX and all of the other parts of this puzzle. If you are in a hurry you might want to consider engaging a consultant who has some experience with SXE. I happen to know several
Similar threads
- Locked
- Locked
- Scott Snowden
- Progress Blog
- Locked
- Scott Snowden
- Progress Blog
- Locked
- John Iwuozor
- Progress Blog