× 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.



and i'm still amazed at your .6ms time. :)

typical ms is for a competent request is between 100-200ms... nathan.. .6??

I just ran a series of tests... and here are the results (also want to
point out that my end point is in Germany, so not sitting right
beside me)...

according to Postman the entire round trip averaged around... 200ms...
Below are the processing times the actual backend webservices completed
locally on the i...
(and these are parsing a json request and producing a json response - this
is not taking a single data element as an input parm)...

I am very happy with this performance... Not sure what kind of freak
experiment you are working with to achieve .6 ms... do you mean .6 secs???

URL Command Program Request TS sec.ms
RESPONSE GET_CUSTOMER_BANK_ACCOUNT_INFO RST00001R 20200505.170513 .049333
REQUEST 003977/QTMHHTTP/COREIHTTP RST00001R 20200505.170513
RESPONSE GET_CUSTOMER_BANK_ACCOUNT_INFO RST00001R 20200505.170512 .047898
REQUEST 003977/QTMHHTTP/COREIHTTP RST00001R 20200505.170512
RESPONSE GET_CUSTOMER_BANK_ACCOUNT_INFO RST00001R 20200505.170510 .069282
REQUEST 003977/QTMHHTTP/COREIHTTP RST00001R 20200505.170510
RESPONSE GET_CUSTOMER_BANK_ACCOUNT_INFO RST00001R 20200505.170509 .055810
REQUEST 003977/QTMHHTTP/COREIHTTP RST00001R 20200505.170509
RESPONSE GET_CUSTOMER_BANK_ACCOUNT_INFO RST00001R 20200505.170508 .033557
REQUEST 003977/QTMHHTTP/COREIHTTP RST00001R 20200505.170508


jay






On Tue, May 5, 2020 at 1:50 PM Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Actually, I've done hundreds of back-to-back tests. The CPU time is
essentially constant in all cases. However, the latency from network
bandwidth varies quite a bit, which is expected.

My interface only authenticates once, upon Login. After that, no check.
However, for sites that are using HTTP basic authentication, that occurs
for every request.



On Tue, May 5, 2020 at 11:43 AM Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:

Nathan

Please take an average of 5 back to back requests tests... let us know
the
comparisons. To accommodate for any front loaded operations.

Jay

Sent from my iPhone

On May 5, 2020, at 1:21 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

I've been reviewing Jay's product, which includes a generic CGI
program
that calls other RPG programs based on a "routing" table. By saying
table,
I'm referring to an IBM i DB table that developers may use to define
routes.

Part of my review includes performance testing of the
GET_CUSTOMER_BANK_ACCOUNT_INFO sample web service that's included with
the
product. On my server that request consumes 5 milliseconds of CPU time
within HTTP server Jobs.

I compared it to an HTTP interface that I wrote. I tested a web
application
that performs comparable database I/O and generates a comparable output
stream. Under the covers it parses HTTP input (environment variables,
query-string parameters, HTTP headers, cookies, and HTML form
variables).
The result of the parsing is various structured sets of NAME-VALUE
pairs
that can be retrieved by name.

That interface consumes only .6 milliseconds of CPU time. That's about
an
8X performance improvement. I've been trying to account for the
performance
difference. Jay's CGI program uses YAJL under the covers for CGI I/O.
His
HTTP server is also performing basic authentication on every request.
But I
didn't expect to see that big of a performance difference.

Nathan.
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.