Best Appserver Configuration
- Thread starter atuldalvi
- Start date
GregTomkins
Active Member
Too open ended. But I'll give it a shot:
1. Stateless/State-Free only. If you try State-Aware or State-Reset, they'll laugh you out of town. Though I know at least one guy who swears by it.
2. You posted about # of AppServers before. Basically, you generally want enough agents available so that nobody has to wait for an AppServer to come available. More than that is generally a waste.
3. Think a lot about remote AppServers. Basically, the performance hit is huge, and there are many little gotchas to worry about (eg. sharing file systems, code deployment etc.), but the killer feature is relatively linear horizontal scalability. If you situation is relatively small, and likely to stay that way, don't bother. AFAIK, in terms of distributing components amongst machines, this is the only thing that matters (unless you get into multiple databases and such).
4. Do you own your own code? If so, do you use the field list feature? This can matter a lot for remote appservers, not so much for local ones. That's not configuration though.
5. If you put AIA's in front of your AppServers, that will cost you a lot, but you might need to.
6. We have an elaborate background-processing system, eg. so an interactive user can launch a task that might run for 3 minutes. The task itself runs in a daemon outside of the AppServer system, this way we can serialize everything without making users wait. We rely hugely on this. I can explain it more if you care, but that's the basic idea. This is a big issue requiring lots of supporting software, though; not just a config thing, which is what your question implies.
That's all I can think of right now
1. Stateless/State-Free only. If you try State-Aware or State-Reset, they'll laugh you out of town. Though I know at least one guy who swears by it.
2. You posted about # of AppServers before. Basically, you generally want enough agents available so that nobody has to wait for an AppServer to come available. More than that is generally a waste.
3. Think a lot about remote AppServers. Basically, the performance hit is huge, and there are many little gotchas to worry about (eg. sharing file systems, code deployment etc.), but the killer feature is relatively linear horizontal scalability. If you situation is relatively small, and likely to stay that way, don't bother. AFAIK, in terms of distributing components amongst machines, this is the only thing that matters (unless you get into multiple databases and such).
4. Do you own your own code? If so, do you use the field list feature? This can matter a lot for remote appservers, not so much for local ones. That's not configuration though.
5. If you put AIA's in front of your AppServers, that will cost you a lot, but you might need to.
6. We have an elaborate background-processing system, eg. so an interactive user can launch a task that might run for 3 minutes. The task itself runs in a daemon outside of the AppServer system, this way we can serialize everything without making users wait. We rely hugely on this. I can explain it more if you care, but that's the basic idea. This is a big issue requiring lots of supporting software, though; not just a config thing, which is what your question implies.
That's all I can think of right now
TheMadDBA
Active Member
Outside of the basics of appserver configuration.... a huge percentage of actual performance and perceived performance is going to depend on your code.
Make too many calls to satisfy an application function and you will have issues with latency. Read too many records from the database or over the network and you will have issues on the database and/or network side.
Start with analyzing and tweaking the code... then you can tweak the various configuration settings for client/appserver startup (-T, -Bt, -tmpbsize, etc.). Then go back to the code again... and again.
Make too many calls to satisfy an application function and you will have issues with latency. Read too many records from the database or over the network and you will have issues on the database and/or network side.
Start with analyzing and tweaking the code... then you can tweak the various configuration settings for client/appserver startup (-T, -Bt, -tmpbsize, etc.). Then go back to the code again... and again.
Similar threads
- Locked
