smtpmail.p performance issues

M

maindave2

New Member
Hi Folks,

Tough one here.

We have quite happily been using the rather excellent smtpmail.p to send emails. One problem - If I run it as Fat Client from my PC an email (no attachments) is sent in less than a second. If I run it from the tram-lines from a pro session on UNIX the email goes in the same sort of time

If I call smtpmail using A/AS from my client the email takes up to 10 seconds.

All our other AS programs work fine.

Our clients are Windows XP and the servers are HP-UX 11.

When I put etst timings in smtpmail.p it simply appears that the SMTP server is slow in responding. Why should introducing AS into the equation effect performance ?

Very confused.

Any ideas please ??

Thanks in anticipation.
 
Hi Dave,

Can you clarify: AS = Appserver? What session model (though I don't know this will be relevant to this particular issue)?

What is A/AS?

Are you on the latest version of smtpmail? (57, I think).

What version of PROGRESS are you on? Are you on the latest patch for your version?

How are you timing? What is etst? etime?

====

I infer from your post that you issue an appserver call client side, which launches smtpmail server-side, and the delay starts when you are actually within smtpmail itself.

If so, I understand your bemusement - why should the SAME code execute more slowly? - perhaps you could locate the exact lines of code/calls that produce the delay.

Have you used non-4GL analysis mechanisms to narrow your focus, eg. -logging/-yx/SHOW-STATS/EXECUTION-LOG (Progress version is important here).

Have you pared down the context to a skeleton call, so nothing else is clouding the issue, and are you issuing the call in the same way with the same parameters each time (in 'good' and 'bad' processes)?

The only thing I can suggest is that becase the thread that smtpmail is running in is owned by a different process, there may be environmental, security/communication or memory leak issues, which are either caused or brought to light by the new context.

Unfortunately, all of those may be obscure and difficult to resolve, and most likely solved by consulting Sys / Email Admin / Progress Tech Support / Upgrading to the latest patch. However, the above mentioned analysis tools may give you more to go on.

On a seperate note, as you say, smtpmail is excellent, but because it does low level stuff with sockets and memory pointers, there are occasional issues (not necessarily the fault of said program). For this reason, I prefer to run it from a background processor, to lessen the chance of a client-side crash when a problem occurs when running through a connected appserver (not terribly relevant to your question, I know).

Sorry my suggestions are a bit indirect, but if any of them are new to you, perhaps they may give you a little more ammunition to trap the problem.

I'll try to help further if I can think of anything, but if you resolve the problem off-board, please post the solution here.
 
Hi There,

App Server yes. Progress : 9.1E04, sendmail.p (5.7).

'I infer from your post that you issue an appserver call client side, which launches smtpmail server-side, and the delay starts when you are actually within smtpmail itself.' - that's correct yes.

I haven't used non-4GL tools to analyse performance.

Thanks for the reply - I'd come to similar conclusions myself and we were going to start on a batch version - i.e. write email details to a table and have a job that polls for these and sends them out.

However, it's one of those problems that's 'eating' away at me and will continue to investigate. I'll definately post if I find a resolution.

Many Thanks,
Dave.
 
You might want to try 5.7a. There was just a post on the PEG about fixes in it. Don't know if it is related, but never hurts to try.
 
You must log in or register to reply here.
Back
Top