473,322 Members | 1,690 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

ServerXMLHTTP uses 100% CPU for a long time

I'm trying to use ServerXMLHTTP on an ASP (not ASP.NET) page to retrieve
large binary data from a remote server. When the request is large (more than
a few megabytes), the ServerXMLHTTP page jumps to nearly 100% CPU utilization
for an unusually long time. The remote server needs a few seconds to prepare
the request, during which time the CPU seems OK. It seems that as soon as
the data is ready to retrieve, the CPU usage jumps and remains that way until
the data has all been copied to the requesting server. That takes way too
long - about 35 seconds when requesting a 12 MB file over a gigabit Ethernet.

I use ServerXMLHTTP hundreds of thousands of times daily on this same system
on the same network, with absolutely no problem - but for smaller requests.
There's something about the size of the request that makes it blow up.

I saw some reports of older systems with this problem (Windows 2000), but
I'm running IIS 6 on Windows Server 2003, SP1. Thanks!
Dec 2 '05 #1
7 2382
Ed McNierney wrote:
I'm trying to use ServerXMLHTTP on an ASP (not ASP.NET) page to
retrieve large binary data from a remote server. When the request is
large (more than a few megabytes), the ServerXMLHTTP page jumps to
nearly 100% CPU utilization for an unusually long time. The remote
server needs a few seconds to prepare the request, during which time
the CPU seems OK. It seems that as soon as the data is ready to
retrieve, the CPU usage jumps and remains that way until the data has
all been copied to the requesting server. That takes way too long -
about 35 seconds when requesting a 12 MB file over a gigabit
Ethernet.

I use ServerXMLHTTP hundreds of thousands of times daily on this same
system on the same network, with absolutely no problem - but for
smaller requests. There's something about the size of the request
that makes it blow up.

I saw some reports of older systems with this problem (Windows 2000),
but I'm running IIS 6 on Windows Server 2003, SP1. Thanks!


Reminds me of the oldie, but goodie:

Patient: Doctor, it hurts when I raise my arm
Doctor: So stop raising your arm!
;-)

Sounds to me as if a different technology is needed for this - perhaps FTP?
Bob Barrows

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.
Dec 2 '05 #2
Bob -

Thanks for the quick reply!

First, I'd like to understand the problem, not ignore it. That won't get it
fixed.

Second, I don't have an option of a different technology. The service that
is producing these files (they're images, produced on the fly based on an
HTTP request) serves them via an HTTP interface, not FTP or any other.

I did a lot of searching and cannot find any other example of this problem
(other than old ones). The "alternative technology" available to me is to
move this portion of the site to a Linux server, where my older PHP code
works flawlessly. The intent was to move the entire site to Windows, but if
Windows can't cut it, I'll need to stick to Linux.

"Bob Barrows [MVP]" wrote:
Ed McNierney wrote:
I'm trying to use ServerXMLHTTP on an ASP (not ASP.NET) page to
retrieve large binary data from a remote server. When the request is
large (more than a few megabytes), the ServerXMLHTTP page jumps to
nearly 100% CPU utilization for an unusually long time. The remote
server needs a few seconds to prepare the request, during which time
the CPU seems OK. It seems that as soon as the data is ready to
retrieve, the CPU usage jumps and remains that way until the data has
all been copied to the requesting server. That takes way too long -
about 35 seconds when requesting a 12 MB file over a gigabit
Ethernet.

I use ServerXMLHTTP hundreds of thousands of times daily on this same
system on the same network, with absolutely no problem - but for
smaller requests. There's something about the size of the request
that makes it blow up.

I saw some reports of older systems with this problem (Windows 2000),
but I'm running IIS 6 on Windows Server 2003, SP1. Thanks!


Reminds me of the oldie, but goodie:

Patient: Doctor, it hurts when I raise my arm
Doctor: So stop raising your arm!
;-)

Sounds to me as if a different technology is needed for this - perhaps FTP?
Bob Barrows

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Dec 2 '05 #3
From
http://support.microsoft.com/default...WCT052802.asp:

.... Another limitation, which we touched on earlier, is that WinInet doesn't
handle some of the higher-level content-related services with regard to HTTP
data. Some of those things are handled by URLMON. Particularly, URLMON
implements MIME type detection and implements HTTP compression.
HTTP compression is a unique technology on your server that says, "Please
gzip this data, compress it before it gets sent to the client." The client
sees it, sees the header indicating that it's gzipped content, and
decompresses it before displaying. If you have a large amount of content
you're sending, then the cost of performing this compression and
decompression can be much less than the cost of transmitting the
uncompressed content down from the server to the client. However, this is
implemented at the URLMON level. Because ServerXMLHTTP doesn't use URLMON,
it goes through WinHTTP, it uses a more bare-bones interface, it can't
handle HTTP compression and, again, there is no MIME type detection at all.
Use that at your own risk and your own best judgment.

However, according to this:
http://groups.google.com/group/micro...4482f75218b1b1

There is a known performance issue that sas fixed in SP3 for MSXML 3.0

What version of MSXML are you using?

Ed McNierney wrote:
Bob -

Thanks for the quick reply!

First, I'd like to understand the problem, not ignore it. That won't
get it fixed.

Second, I don't have an option of a different technology. The
service that is producing these files (they're images, produced on
the fly based on an HTTP request) serves them via an HTTP interface,
not FTP or any other.

I did a lot of searching and cannot find any other example of this
problem (other than old ones). The "alternative technology"
available to me is to move this portion of the site to a Linux
server, where my older PHP code works flawlessly. The intent was to
move the entire site to Windows, but if Windows can't cut it, I'll
need to stick to Linux.

"Bob Barrows [MVP]" wrote:
Ed McNierney wrote:
I'm trying to use ServerXMLHTTP on an ASP (not ASP.NET) page to
retrieve large binary data from a remote server. When the request
is large (more than a few megabytes), the ServerXMLHTTP page jumps
to nearly 100% CPU utilization for an unusually long time. The
remote server needs a few seconds to prepare the request, during
which time the CPU seems OK. It seems that as soon as the data is
ready to retrieve, the CPU usage jumps and remains that way until
the data has all been copied to the requesting server. That takes
way too long - about 35 seconds when requesting a 12 MB file over a
gigabit Ethernet.

I use ServerXMLHTTP hundreds of thousands of times daily on this
same system on the same network, with absolutely no problem - but
for smaller requests. There's something about the size of the
request that makes it blow up.

I saw some reports of older systems with this problem (Windows
2000), but I'm running IIS 6 on Windows Server 2003, SP1. Thanks!


Reminds me of the oldie, but goodie:

Patient: Doctor, it hurts when I raise my arm
Doctor: So stop raising your arm!
;-)

Sounds to me as if a different technology is needed for this -
perhaps FTP? Bob Barrows

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get
a quicker response by posting to the newsgroup.


--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.
Dec 2 '05 #4
Bob -

Thanks again for the quick replies. There is no HTTP compression involved,
and I was running on MSXML 4.0 and then upgraded to MSXML 6.0 to see if this
bug was fixed. There was no apparent difference in behavior between 4.0 and
6.0.

I did read the item you mention about the MSXML 3.0 bug because the symptom
sounds virtually identical. But I have found no mention of a similar bug in
4.0 or 6.0, which I would have expected if there was regression from 3.0
(e.g. if the SP3 bug fix never made it to 4.0).

- Ed

"Bob Barrows [MVP]" wrote:
From
http://support.microsoft.com/default...WCT052802.asp:

.... Another limitation, which we touched on earlier, is that WinInet doesn't
handle some of the higher-level content-related services with regard to HTTP
data. Some of those things are handled by URLMON. Particularly, URLMON
implements MIME type detection and implements HTTP compression.
HTTP compression is a unique technology on your server that says, "Please
gzip this data, compress it before it gets sent to the client." The client
sees it, sees the header indicating that it's gzipped content, and
decompresses it before displaying. If you have a large amount of content
you're sending, then the cost of performing this compression and
decompression can be much less than the cost of transmitting the
uncompressed content down from the server to the client. However, this is
implemented at the URLMON level. Because ServerXMLHTTP doesn't use URLMON,
it goes through WinHTTP, it uses a more bare-bones interface, it can't
handle HTTP compression and, again, there is no MIME type detection at all.
Use that at your own risk and your own best judgment.

However, according to this:
http://groups.google.com/group/micro...4482f75218b1b1

There is a known performance issue that sas fixed in SP3 for MSXML 3.0

What version of MSXML are you using?

Ed McNierney wrote:
Bob -

Thanks for the quick reply!

First, I'd like to understand the problem, not ignore it. That won't
get it fixed.

Second, I don't have an option of a different technology. The
service that is producing these files (they're images, produced on
the fly based on an HTTP request) serves them via an HTTP interface,
not FTP or any other.

I did a lot of searching and cannot find any other example of this
problem (other than old ones). The "alternative technology"
available to me is to move this portion of the site to a Linux
server, where my older PHP code works flawlessly. The intent was to
move the entire site to Windows, but if Windows can't cut it, I'll
need to stick to Linux.

"Bob Barrows [MVP]" wrote:
Ed McNierney wrote:
I'm trying to use ServerXMLHTTP on an ASP (not ASP.NET) page to
retrieve large binary data from a remote server. When the request
is large (more than a few megabytes), the ServerXMLHTTP page jumps
to nearly 100% CPU utilization for an unusually long time. The
remote server needs a few seconds to prepare the request, during
which time the CPU seems OK. It seems that as soon as the data is
ready to retrieve, the CPU usage jumps and remains that way until
the data has all been copied to the requesting server. That takes
way too long - about 35 seconds when requesting a 12 MB file over a
gigabit Ethernet.

I use ServerXMLHTTP hundreds of thousands of times daily on this
same system on the same network, with absolutely no problem - but
for smaller requests. There's something about the size of the
request that makes it blow up.

I saw some reports of older systems with this problem (Windows
2000), but I'm running IIS 6 on Windows Server 2003, SP1. Thanks!

Reminds me of the oldie, but goodie:

Patient: Doctor, it hurts when I raise my arm
Doctor: So stop raising your arm!
;-)

Sounds to me as if a different technology is needed for this -
perhaps FTP? Bob Barrows

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get
a quicker response by posting to the newsgroup.


--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Dec 2 '05 #5
I think what he was saying is that with URLMon, http compression is
automatically used, reducing the download time. With WinInet, it can't be
used.

Otherwise, I am out of my depth there. You may want to try the
..inetserver.iis group (or even one of the xml groups) if nobody else steps
up to the plate here.

If you do get a solution, I would appreciate hearing about it.

Bob

Ed McNierney wrote:
Bob -

Thanks again for the quick replies. There is no HTTP compression
involved, and I was running on MSXML 4.0 and then upgraded to MSXML
6.0 to see if this bug was fixed. There was no apparent difference
in behavior between 4.0 and
6.0.

I did read the item you mention about the MSXML 3.0 bug because the
symptom sounds virtually identical. But I have found no mention of a
similar bug in
4.0 or 6.0, which I would have expected if there was regression from
3.0 (e.g. if the SP3 bug fix never made it to 4.0).

- Ed

"Bob Barrows [MVP]" wrote:
From
http://support.microsoft.com/default...WCT052802.asp:
.... Another limitation, which we touched on earlier, is that
WinInet doesn't handle some of the higher-level content-related
services with regard to HTTP data. Some of those things are handled
by URLMON. Particularly, URLMON implements MIME type detection and
implements HTTP compression.
HTTP compression is a unique technology on your server that says,
"Please gzip this data, compress it before it gets sent to the
client." The client sees it, sees the header indicating that it's
gzipped content, and decompresses it before displaying. If you have
a large amount of content you're sending, then the cost of
performing this compression and decompression can be much less than
the cost of transmitting the uncompressed content down from the
server to the client. However, this is implemented at the URLMON
level. Because ServerXMLHTTP doesn't use URLMON, it goes through
WinHTTP, it uses a more bare-bones interface, it can't handle HTTP
compression and, again, there is no MIME type detection at all. Use
that at your own risk and your own best judgment.

However, according to this:
http://groups.google.com/group/micro...4482f75218b1b1
There is a known performance issue that sas fixed in SP3 for MSXML
3.0

What version of MSXML are you using?

Ed McNierney wrote:
Bob -

Thanks for the quick reply!

First, I'd like to understand the problem, not ignore it. That
won't get it fixed.

Second, I don't have an option of a different technology. The
service that is producing these files (they're images, produced on
the fly based on an HTTP request) serves them via an HTTP interface,
not FTP or any other.

I did a lot of searching and cannot find any other example of this
problem (other than old ones). The "alternative technology"
available to me is to move this portion of the site to a Linux
server, where my older PHP code works flawlessly. The intent was to
move the entire site to Windows, but if Windows can't cut it, I'll
need to stick to Linux.

"Bob Barrows [MVP]" wrote:

Ed McNierney wrote:
> I'm trying to use ServerXMLHTTP on an ASP (not ASP.NET) page to
> retrieve large binary data from a remote server. When the request
> is large (more than a few megabytes), the ServerXMLHTTP page jumps
> to nearly 100% CPU utilization for an unusually long time. The
> remote server needs a few seconds to prepare the request, during
> which time the CPU seems OK. It seems that as soon as the data is
> ready to retrieve, the CPU usage jumps and remains that way until
> the data has all been copied to the requesting server. That takes
> way too long - about 35 seconds when requesting a 12 MB file over
> a gigabit Ethernet.
>
> I use ServerXMLHTTP hundreds of thousands of times daily on this
> same system on the same network, with absolutely no problem - but
> for smaller requests. There's something about the size of the
> request that makes it blow up.
>
> I saw some reports of older systems with this problem (Windows
> 2000), but I'm running IIS 6 on Windows Server 2003, SP1. Thanks!

Reminds me of the oldie, but goodie:

Patient: Doctor, it hurts when I raise my arm
Doctor: So stop raising your arm!
;-)

Sounds to me as if a different technology is needed for this -
perhaps FTP? Bob Barrows

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will
get a quicker response by posting to the newsgroup.


--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get
a quicker response by posting to the newsgroup.


--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.
Dec 2 '05 #6

"Ed McNierney" <Ed*********@discussions.microsoft.com> wrote in message
news:F9**********************************@microsof t.com...
Bob -

Thanks again for the quick replies. There is no HTTP compression
involved,
and I was running on MSXML 4.0 and then upgraded to MSXML 6.0 to see if
this
bug was fixed. There was no apparent difference in behavior between 4.0
and
6.0.

I did read the item you mention about the MSXML 3.0 bug because the
symptom
sounds virtually identical. But I have found no mention of a similar bug
in
4.0 or 6.0, which I would have expected if there was regression from 3.0
(e.g. if the SP3 bug fix never made it to 4.0).


Hi Ed,

You can use some alternatives.
ADODB.Record
and ADODB.Stream can use http uploads and logon to remote pages.

Aditionally, you always should send large data, chunked, in loops, say
blocks of data of 4096 KB. Within the loop, you test for connectivity
issues.

Dec 3 '05 #7
Egbert Nierop (MVP for IIS) wrote:
"Ed McNierney" <Ed*********@discussions.microsoft.com> wrote in
message news:F9**********************************@microsof t.com...
Bob -

Thanks again for the quick replies. There is no HTTP compression
involved,
and I was running on MSXML 4.0 and then upgraded to MSXML 6.0 to see
if this
bug was fixed. There was no apparent difference in behavior between
4.0 and
6.0.

I did read the item you mention about the MSXML 3.0 bug because the
symptom
sounds virtually identical. But I have found no mention of a
similar bug in
4.0 or 6.0, which I would have expected if there was regression from
3.0 (e.g. if the SP3 bug fix never made it to 4.0).


Hi Ed,

You can use some alternatives.
ADODB.Record
and ADODB.Stream can use http uploads and logon to remote pages.

Aditionally, you always should send large data, chunked, in loops, say
blocks of data of 4096 KB. Within the loop, you test for connectivity
issues.


Both good suggestions. I wish I had thought of making them.

Bob
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Dec 3 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: c45aed | last post by:
We currently have a multi-homed ISA Server (one NIC to the Internet, one to the internal LAN). However, we are currently running our web server on the same box as the ISA server (not good, I know)...
0
by: Ytsejammer | last post by:
I'm trying to find answers to my questions about ServerXMLHttp... We have the following (simplified) piece of VB6 code on a component, that is accessed thousands of times per day: --- On Error...
0
by: anshu | last post by:
Hi, I've to migrate an existing code in asp to asp.Net. The asp code uses ServerXMLHTTP to call some services. Same thing will be done using HttpWebRequest in the asp.Net code. The problem is...
2
by: David | last post by:
Hi, I am very new to XML and webservices. The server that I have to write a client for is NOT a .NET webservice, but has a bunch of ASP pages that takes XML requests and spits out XML strings...
2
by: Maris Janis Vasilevskis | last post by:
Hi, Is it possible to force HttpWebRequest to do exactly (not approximately) the same as MSXML2.ServerXMLHTTP does? More details. I port JScript to JScript.NET I have a server (ASP invoking...
8
by: Dave Brown | last post by:
I am attempting to post to a url (https://FakeURL/logon.asp) using the HttpWebRequest class. The response for a succesful post will contain the html for the logon user's default page. We've...
0
by: Leilamir | last post by:
Hi there, We are having a problem with the following code. This asp page (as you can see in the code) creates a ServerXMLHTTP object and posts an xml object (xmlRequest) to another asp page and...
1
by: niklang | last post by:
Hi everybody, I have an ASP page that uses the MSXML2.ServerXMLHTTP object to read a stylesheet from IIS as follows: strXSLPath = "http://localhost/ej/ejdetail.xsl.asp" ...
7
by: Adam David Moss | last post by:
All, Long time since I've done some proper coding in ASP and I've hit a wee snag that has got me baffled. Well two actually but the other is to do with running pages under Sun ASP so we'll not...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.