× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Web server performance
  • From: "Stone, Brad V (TC)" <bvstone@xxxxxxxxxxxxxx>
  • Date: Fri, 17 Dec 1999 10:55:13 -0600

Most likely not.  I have a set of wrappers that manipulate the libl  and I
haven't noticed a hit from them.

I do notice that the first call to a CGI program is slower than subsequent
calls that use the same job in the instance.  This tells me its AG creation
that is part of the speed problem.

Then again, 5 seconds isn't really anything to sneeze at.  It's not bad at
all.  You also have to take into play network load, connection speed, etc.
Also, programming techniques as well.  Setting on LR won't be a big deal (in
the main program) since it only happens once and after all the HTML is
written to the screen.  But, if you're calling a program multiple times that
sets on LR, making the program a service program would help.  I have two
modules... one that writes the HTML stored in a member and another that
writes HTML stored in a stream file.

Bradley V. Stone
BVS/Tools - www.bvstools.com
Netshare400 - www.netshare400.com



> -----Original Message-----
> From: Martin, Booth [mailto:BoothM@goddard.edu]
> Sent: Friday, December 17, 1999 10:32 AM
> To: 'RPG400-L@midrange.com'
> Subject: RE: Web server performance
> 
> 
> Is the changing of the library list a performance hit, with all of the
> associated security checking?  What happens, performance-wise, if the
> library list does not need to be adjusted?
> 
> -----Original Message-----
> From: Denis Robitaille [mailto:DRobitaille@cascades.com]
> Sent: Friday, December 17, 1999 11:04 AM
> To: boothm@goddard.edu
> Subject: Re: Web server performance
> 
> 
> You should check if your programs set LR on before leaving. 
> This can be a
> cause of performance problem if the programs are called 
> repetidely. You
> could yous bound program or service program to improve 
> performance. You
> could also replace the QCMDEXC by calls to IBM API, it is 
> more complicated
> but likely faster.
> 
> Denis Robitaille
> Directeur service technique
> Cascades Inc
> 819 363 5187
> fax 819 363 5177
> 
> 
> >>> "Scott Adams" <as400jockey@hotmail.com> 12/17 10:06 AM >>>
> I have a 170-2189 with 128MB memory.  I've been playing with 
> the HTTP server
> 
> stuff.
> 
> The performance on HTML based stuff, either in IFS 
> directories or in source 
> files is pretty good.  The problem is with performance of RPG 
> programs.  I 
> have one program that does the following:
> 
>    -  calls QCMDEXC to change the lib list
>    -  calls several other RPG programs to create the various 
> sections of the
> 
> screen - top bar, left and right bar, bottom bar, etc
>    -  calls another RPG program to create a random number
> 
> This collection of stuff takes about 5 seconds before any 
> HTML starts coming
> 
> back to the client.  Once that starts, the screen appears 
> very quickly.  The
> 
> first program is about 180K (optimized) and all the other 
> little programs 
> tip the scales at about 40K each.
> 
> In short, this performance is not great.  Does anyone have 
> recommendations 
> as to how to speed things up?  Could my problems be caused by 
> any of the 
> following:
> 
> - insufficient memory (there's nothing else going on with the 
> machine) and 
> it's hard to determine from WRKSYSSTS if there's too much 
> paging going on
> - calling QCMDEXC from inside RPG
> - calling other RPG programs from within this RPG program
> 
> How do I find out where the bottleneck is?
> 
> Thanks in advance for any help.
> 
> 
> 
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com 
> 
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com 
> +---
> 
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: 
> david@midrange.com
> +---
> 
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.