(...Rejoining thread with Cftalk list....)

John,

Makes sense.  From what you are saying, the HTTP requests are dependent
on a web service, and that is the bottlenecking factor.

This means, you won't be able to speed it up, since a
web-service-request is needed per request, so serializing your requests
might help sometimes, but you're assuming nobody else is also using the
web service.. A web service which cant handle concurrency will probably
always be your bottleneck.

Here are some points to consider:

1) Locking Overhead in this case : If locking were to help (and in this
case, I don't see how it would), the overhead would be minimal if you're
protecting access to a slow cfhttp request.  No matter what you do,
you'd be queueing up requests in cf, preventing it from working on any
other cf pages being served out.

---> what would be nice (and maybe this is possible, I'm not totally up
to speed with cf6.1's new features) is if CF could allow you to specify
named queues at the server level, and specify that if this web page were
to queue up on the cf server, it should go into its own queue. This
would prevent (in theory, if done right) all other cf pages to wait for
the bottlenecking pages.

2) Question:   - Do you need these images stored on disk, or are they
just stored to serve out to the user?  If the latter, why not run a
separate web server which may or may not be CF-based, to proxy requests
to the web service, and pushes the content to the browser? You can get a
cheap web server hosting account and with a little perl or server-side
asp, etc. you can write a page which pushes GIF's based on query
strings...  i.e. img
src=""> d=to&web=server....'  -  This would take the responsibility and load off
of your cf server.

Just some ideas and comments...
-Dov


> -----Original Message-----
> From: John McCosker [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 02, 2004 6:34 AM
> To: Katz, Dov B (IT)
> Subject: RE: cfhttp
>
> Yea your right,
>
> how did I get so slack, CreateUUID will be unique per request
> so effectively undermining the lock.
> The site I am connecting to as far as I am aware supports
> concurrency but under heavy traffic cfhttp is slow and in
> some cases the image never loads. So this led me to think
> that locking would resolve the issue.
>
> Of course there is overhead associated with locking, and I'm
> wondering would locking by one unique name resolve issues
> with the cfhttp call.
>
> A schedule would not resolve the issue as its created on per
> request, the user selects what they want and longitude and
> lititudes are placed into xml which send hte packet to the
> web service, the service returns a gif image. This could'nt
> really be done via a schedule as its all interaction based.
> -----Original Message-----
> From: Katz, Dov B (IT) [mailto:[EMAIL PROTECTED]
> Sent: 02 March 2004 10:59
> To: [EMAIL PROTECTED]
> Subject: RE: cfhttp
>
>
> John,
> (perhaps repost to the list, it doesnt like me when I use outlook web
> access)
>
> CFLOCK doesn't seem to buy you anything here, especially
> since the name is
> unique, and presumably no other lock is created with the same
> name.... ..
>
> What is your logic? How are you trying to protect from a
> slowdown? If you
> are periodically getting images, you might want to run scheduled tasks
> independently of use of the web app.
>
> The bottom line is, I don't understand how you are trying to
> save the server
> any work...
> I usually use CFLOCK like below...
>
> <CFIF i DONT need to do the intense operations>
> do something with the results of the last run of the intense
> operations
> if i am reading from a file i might write within the lock
> below, i might
> cflock around the CFFILE read only... with a timeout...
> <CFELSE>
> <CFLOCK type="exclusive" name="MyLockName">
> LOAD INTENSIVE OPERATIONS,
> If you are performing an operation which is generating or
> downloading files,
> I'd start with a temp file, and then rename it in a single
> operation. That
> way if it fails, you lose nothing....
> </CFLOCK>
> </CFIF>
>
> HTH
> -dov
> -----Original Message-----
> From: John mccosker [mailto:[EMAIL PROTECTED]
> Sent: Tue 3/2/2004 4:42 AM
> To: CF-Talk
> Cc:
> Subject: cfhttp
>
>
> Hi, what is the best way to lock cfhttp when facing hi
> transaction traffic.
> I was thinking something along the lines of this <cflock
> name="#CreateUUID()#" timeout="60"><CFHTTP METHOD="GET"
> URL=""
> PATH="#REQUEST.StoreMapRoot#" FILE="#MAP_NAME##COOKIE.MAP_COUNT#.gif">
>
> <CFHTTPPARAM TYPE="FORMFIELD" VALUE="#XML_STREAM#" NAME="xmlparams">
>
> </CFHTTP></cflock>, We have noticed that the pages run very
> slow that call
> cfhttp when traffic is at its highest. Thanks for any advice, J.
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to