Mailing List Archive

Alternatives to SSI (server side includes)?
I have been using server side includes since I started my websites on
Apache about 10 years ago. The performance hit I'm getting is too high and
I would like to get the same utility with something more modern and
appropriate.

What I have been doing with SSI is executing some fairly involved db
programs to track and update the visitor's who use the site, but the
handling delay during page load is getting too large. I suspect I could
speed them up but haven't looked into actual debugging yet.

Any suggestions for SSI replacement with a more asynchronous method?

Best regards,

-Tom
Re: Alternatives to SSI (server side includes)? [ In reply to ]
On Sat, Oct 3, 2020 at 12:18 Tom Browder <tom.browder@gmail.com> wrote:
> I have been using server side includes since I started my websites on Apache
...
> Any suggestions for SSI replacement with a more asynchronous method?

Let me be more specific about the data flow I'm using with the landing
(home) page of my websites:

+ the first SSI line executes a CGI program that extracts the CGI and
SSL variables and their values. Data of interest include: requesting
IP, email address in the SSL client certificate, time of page load

+ the second line executes a CGI program that generates a link to a
page that presents the current and past statistics of the visitor
based on the stats in the db updated with the first CGI program

-Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: Re: Alternatives to SSI (server side includes)? [ In reply to ]
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 seeing if SSI is a loser in its entirety or if it's one specific part of the process that is tanking your page load times that you can easily fix (you don't say much about that data store, but if you've crossed a tipping in regards to size or number of records, you may need to reconsider your data storage strategy).

Also, if you've got really old / dumb clients AJAX might not be a great answer whereas SSI is always entirely under your control.

Best of luck,

Scott

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

On Sat, Oct 3, 2020 at 12:18 Tom Browder <tom.browder@gmail.com> wrote:
> I have been using server side includes since I started my websites on Apache
...
> Any suggestions for SSI replacement with a more asynchronous method?

Let me be more specific about the data flow I'm using with the landing
(home) page of my websites:

+ the first SSI line executes a CGI program that extracts the CGI and
SSL variables and their values. Data of interest include: requesting
IP, email address in the SSL client certificate, time of page load

+ the second line executes a CGI program that generates a link to a
page that presents the current and past statistics of the visitor
based on the stats in the db updated with the first CGI program

-Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: Re: Alternatives to SSI (server side includes)? [ In reply to ]
On Sat, Oct 3, 2020 at 13:46 Scott A. Wozny <sawozny@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
Re: Re: Alternatives to SSI (server side includes)? [ In reply to ]
hi Tom,

I simply use (or dynamically construct) a page with iframes, in which
each iframe gets loaded by a separate CGI results;
this is the async way. You can trigger the loading of certain iframes
when user clicks on some button in the main part of the page, then a
Javascript function is called by that button to re-load the contents
of some iframe by a corresponding CGI.
No AJAX needed, but plain HTML + Javascript.

cheers
Rob

Quoting "Scott A. Wozny" <sawozny@hotmail.com>:

> 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 seeing if SSI is a loser in its
> entirety or if it's one specific part of the process that is tanking
> your page load times that you can easily fix (you don't say much
> about that data store, but if you've crossed a tipping in regards to
> size or number of records, you may need to reconsider your data
> storage strategy).
> ?
> Also, if you've got really old / dumb clients AJAX might not be a
> great answer whereas SSI is always entirely under your control.
> ?
> Best of luck,
> ?
> Scott
> ?
>
> -------------------------
> FROM: Tom Browder <tom.browder@gmail.com>
> SENT: October 3, 2020 2:08 PM
> TO: users@httpd.apache.org <users@httpd.apache.org>
> SUBJECT: [users@httpd] Re: Alternatives to SSI (server side
> includes)? ?
>
> On Sat, Oct 3, 2020 at 12:18 Tom Browder
> <tom.browder@gmail.com> wrote:
>> I have been using server side includes since I started my websites on Apache
> ...
>> Any suggestions for SSI replacement with a more asynchronous method?
>
> Let me be more specific about the data flow I'm using with the landing
> (home) page of my websites:
>
> + the first SSI line executes a CGI program that extracts the CGI and
> SSL variables and their values. Data of interest include: requesting
> IP, email address in the SSL client certificate, time of page load
>
> + the second line executes a CGI program that generates a link to a
> page that presents the current and past statistics of the visitor
> based on the stats in the db updated with the first CGI program
>
> -Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
> ?
Re: Re: Alternatives to SSI (server side includes)? [ In reply to ]
On Sun, Oct 4, 2020 at 04:38 Rob De Langhe <rob.de.langhe@twistfare.be>
wrote:

> I simply use (or dynamically construct) a page with iframes, in which each
> iframe gets loaded by a separate CGI results;
>
Hm, I've always thought that iframes were frowned upon in modern practice.
I'll have to read up on them

Thanks, Rob.

Cheers,

-Tom
Re: Re: Alternatives to SSI (server side includes)? [ In reply to ]
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.browder@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 <sawozny@hotmail.com<mailto:sawozny@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
Re: Alternatives to SSI (server side includes)? [ In reply to ]
On 10/3/20 10:18 AM, Tom Browder wrote:

> What I have been doing with SSI is executing some fairly involved db programs to
> track and update the visitor's who use the site, but the handling delay during
> page load is getting too large. I suspect I could speed them up but haven't
> looked into actual debugging yet.
>
Aren't cookies good for this type of tracking?
Your description of the backend processing does not seem to preclude their use.

--
James Moe
moe dot james at sohnen-moe dot com
520.743.3936
Think.
Re: Re: Alternatives to SSI (server side includes)? [ In reply to ]
On Sun, Oct 4, 2020 at 13:05 Scott A. Wozny <sawozny@hotmail.com> wrote:

> IMHO, Web Sockets aren't going to get you any real benefit here. The
> primary
>

Thanks, Scott. I do intend to look into the timing.

BTW, this website takes over eight seconds to load, and it uses the same
CGI setup as my other sites:

https://psrr.info

Cheers!

-Tom
Re: Alternatives to SSI (server side includes)? [ In reply to ]
On Sun, Oct 4, 2020 at 17:49 James Moe <jimoe@sohnen-moe.com.invalid> wrote:
...

> Aren't cookies good for this type of tracking?


I don't think data from cookies would be as reliable. Anyway, I just
haven't dealt with cookies up till now and probably won't any time soon.

Thanks.

-Tom