Re: Home page options for Apache on IBMi

Jon



There are many ways to improve performance but you need to know where the
bottleneck is and most times the bottleneck is in the internet connection
and firewall especially if the firewall handles VPN at the same time.



At the same time you need to know who your users are. How many new users
are there on a day and how many users are repeats. The latter is very
likely to have cached your static files in their browsers which mean that
they don’t take up bandwidth loading these static files. Static files is in
this context both html pages and gif's, jpg, css and js files.



If you have many new users or you stream a lot of real time data you may
place all your public static files outside your local network since these
static files don’t need to be in the Apache server’s domain.



In my office we have 100/100 Mbit but since my office is in our technical
university campus that also runs one of the three Danish Internet Exchange
Points I could place an external linux server for static file serving in
their datacenter and get 100/100 Gbit directly connected to the
international internet backbone, it is just a matter of money. But if I had
those needs I also had to consider where my users are situated since cross
Atlantic connections would add ~90ms minimum latency to the connections not
to mention the latency NSA creates sniffing on incoming traffic ;-)



This is of course a little off-topic but just a 1ms latency is a long time
for a stock trading robot and a ms is even on IBM power a long time since a
simple RPGLE program roundtrip with powerEXT service program on power6 only
takes approx. 112μs and on a power7 takes approx. 48μs.



So all in all, it all depends but I don’t have a feeling that Joe’s
homepage is a high frequency homepage that is hammered by millions of new
users every day so it may not have any effect if it is served by a CGI
program with dynamic content instead of a static file - but I may of course
be wrong.

On Fri, Jul 17, 2015 at 2:16 AM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

The implication was that the changes were few - that meant it was possible
that even an hourly/daily/whatever timed regeneration might have been
sufficient.

A static page would use less resource and we don’t know how many home page
hits there are.

I was merely pointing out that the complexity of the solution was perhaps
overkill for the situation and just wanted to give the OP something
different to think about.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jul 16, 2015, at 3:49 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Jon

excuse me, but serving a homepage 'on the fly' is much more simple that
introducing
triggers that has to monotor if changes has been made in a given

timeframe.

It is raw and it is KISS just to serve the page

On Thu, Jul 16, 2015 at 9:42 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx>

wrote:

I was thinking along the same lines Bill. Maybe if it needs to be more
dynamic then combine this idea with a trigger or similar event on the
table(s) in question that would regenerate the static page. From the

OP’s

original request it sounds as if anything else is overkill.

Just because we _can_ do fancy things is not a good reason to do them -
particularly when it adds complexity.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jul 16, 2015, at 3:17 PM, William A. Hansen <whansen@xxxxxxxxxxxxx>
wrote:

I was once asked to design a database application for which the optimal

solution was to buy the user a dozen file cards. Reading the posts

makes

me wonder whether we are grossly overdesigning Joe's application.

I have a web site that uses AJAX calls for information that can change

by the second. For another, I used server-side calls to dynamically add
the same header and footer information to the 300+ pages making up the
site. While this worked great, I realized this was overkill for pages

that

might change only once a month. I now store all pages in XML format and
run a job once a month or as needed to recreates the web site using an

XSLT

transform.

Would this problem be solved by running a daily job that simply

recreates the index file?

KISS,

Bill

William A. Hansen
whansen@xxxxxxxxxxxxx
Manta Technologies Inc.
Toll-free: (800) 406-2682 x 101
Direct: (303) 862-4562
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)

mailing

list

To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing

list

To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.