mtx.exe consuming processor

[paulj]

We went live today with an internet application, written in Visual FoxPro, and using MTS. When the user load increased, the response time ground to VERY slow. Looking at the system monitor, we see that mtx.exe is pretty much pegged at 100%.

A few questions, the obvious first.

1. Any idea what could cause this?
2. How can we monitor what the MTS process itself is spending its time doing?
3. Ideas as to how we might go about troubleshooting the situation.

We don't know how many users are pounding away (how can we find that out, but when we limit the concuurent connections to 50 or 75, the performance improves but users then get our "System Busy" message as they move from page to page.

Sure would like a clue where to start, if not the solution itself. I'm afraid that just adding processor power to the web server may not solve the problem.

 

[chiph]

Paul -

Can you tell us more about how your system is architected?

Primarily, if your application requires a user connection to maintain state (and nearly all do), how do you keep track of your users?

What language were your components written in?

Chip H.

 

[paulj]

Hi Chip, thaks for responding. I will have the developer answer some of your questions first thing tomorrow morning. Any help you might be able to provide would be so appreciated. The response on the system today was just fine; a lot less users I'm sure. I don't know how we are going to approach solving the problem because the kind of load we experienced yesterday will happen but once a year. Perhaps we can stress test it until we reach the breaking point.

More processor might be the answer. Moving MTS off the web server onto it's own box might help. But I don't yet want to rule out some design issue in the code so we will get the answers to you tomorrow.

Meanwhile, would you know what tools can we use to monitor the number of sessions IIS is handling?

 

[paulj]

We use ASP pages calling foxpro in-process components containing the business logic. These components which reside on the web server itself call another set of foxpro components which reside on the database server and do the reading and writing to their foxpro accounting system.

Any data that is sent back from the db server components come as a text stream which is un-parsed by the webserver components.

We use a session variable and hidden form controls on the ASP pages to maintain user state.

So for example, if a user makes a request for his or her information to be displayed, he logs in, a "member" object gets created which in turn calls the server component to return data for that user. The member object is destroyed once the data has been displayed on the page.


Thanks for your help.

 

[chiph]

Everything sounds OK thus far. But I'm not a Foxpro developer, so I don't know the details of how it instantiates objects. Under MTS you need to let MTS create the objects for you. That way it is able to recycle from a pool of objects, and not waste time creating objects from scratch every time a new request comes in.

In VB, you implement the ObjectControl interface, and one of the methods you must create is CanBePooled(). You return TRUE if the object can be pooled, or FALSE if not (the required answer for VB 6, since VB 6 doesn't have true multithreading). So it's possible that Foxpro doesn't support it either, and that's the bottleneck.

Chip H.

 

[paulj]

Thanks Chip, I will pass this on to the developer. This pooling feature is one that keeps coming up during our discussions of the problem. Question, if the objects are stateful, as they are, is pooling a problem?

 

[jmarler]

Ideally, object running under MTS and/or Component Services have to be stateless otherwise they will not scale. - Jeff Marler B-)

 

[zallen]

You donot need to explicitly destroy objects creatd under MTX context.You just need to tell MTS that the game is over by calling SetComplete or SetAbort.
For my experience the stateless objects is necessary even if the MTS supports stateful objects.

Regards! zallen@cmmail.com
Long live of freedom!

 

[chiph]

paulj -

Pooling and maintaining state are only distantly related. Here's a scenario for a pool of size 3:

Caller 1 instantiates a copy of object A -- MTS creates a pool of 3, and gives one of them to caller 1
Caller 2 instantiates a copy of object A -- MTS gives one from the pool to caller 2
Caller 3 instantiates a copy of object A -- MTS gives one from the pool to caller 3
Caller 4 instantiates a copy of object A -- MTS has no more copies available -- caller 4 is blocked
Caller 1 releases it's copy of object A
Caller 4 is given a copy of object A -- this object (since it's stateful) has it's contents set to however Caller 1 left it. Caller 4 may behave unpredictably if explicit initialization isn't done.

As you can see, MTS likes callers to grab a copy of an object, use it as quickly as possible, then release it. MTS is able to give you a copy of an object much faster out of it's pool since all the objects in the pool get pre-instantiated, so there's actually a speed benefit in using it.

Chip H.