IMHO, Web Sockets aren't going to get you any real benefit here.  The primary 
point of web sockets is to keep a bidirectional conversation open for the long 
term during a visitor's session which makes it super beneficial to something 
like an infinite scroll, but it sounds like your problem is a one time rendered 
asset that's taking an inordinately long time to return.  That's why I 
suggested AJAX but the other suggestions I've seen of iframes are also 
applicable to what you've given us about your scenario (but without seeing your 
page, iframes may not be a very 'pretty' answer).

When I'm facing an architectural efficiency question like this, I find it 
helpful to remember that the web is a document platform we've mutated into an 
application platform by sheer force of will.  All the server cares about is 
returning each document in isolation.  Everything else that makes it LOOK like 
a web page is responding to the client is JavaScript and CSS voodoo.

In your case it sounds like the limiting factor is how long that individual 
asset takes to return.  Absent a rewrite of the inefficient asset, your primary 
goal is to take that object out of the critical path for the server to complete 
the main page return faster.  In this case without you ALSO adding a way to 
make the slow asset a separate document return and once you've done that (AJAX, 
iframes, etc...), web sockets didn't buy you anything.

However, like all things related to technology, there's a lot of ways to 
accomplish any task.  I still stand by my original suggestion that you at least 
look at the timings on your CGI before considering a total rewrite, though.  🙂

HTH,

Scott

P.S.  Interesting debate on SO about web sockets vs AJAX that evolved over 
several years.  🙂  
https://stackoverflow.com/questions/10377384/why-use-ajax-when-websockets-is-available


________________________________
From: Tom Browder <tom.brow...@gmail.com>
Sent: October 3, 2020 3:29 PM
To: users@httpd.apache.org <users@httpd.apache.org>
Subject: Re: [users@httpd] Re: Alternatives to SSI (server side includes)?

On Sat, Oct 3, 2020 at 13:46 Scott A. Wozny 
<sawo...@hotmail.com<mailto:sawo...@hotmail.com>> wrote:
Sounds like a job for AJAX, but before throwing out the baby with the bath 
water I'd seriously consider turning up logging with timestamps on your 
existing CGI and

That's a good idea, Scott, I've just been too lazy and debugging CGI is such a 
pain.

The clients are mostly casual browsers, but every visitor triggers the CGI so 
that's a lot of work for the db. Regarding the db it's currently an SQLite 
instance but I'm running about 10+ virtual sites off the same db and needing 
writes so that alone may be part of the problem.

Also, I do have a good Pg db running I've intended to use but just haven't 
gotten a "round tuit" yet.

But, could a web socket setup help do you think?

Best,

-Tom

Reply via email to