(Much) slower response handling in netwebclient when using compact json

[AtoB]

HI all,

(using nettalk 14.38 for both server/client, clarion 10)

I ran into a strange but a little concerning issue:

all my endpoints have the option to request for human readable (non-compact) json or json without these spaces/line breaks (compact). I control this via parameter "readable=1" and use the human readable mostly only during testing. This in itself works ok.

Today I (by accident) I ran a GET with the option omitted, so effectively asking for "compact" json against a somewhat larger result/response and this took ages (cpu of het client app hitting the max)

- Human readable response takes 3 seconds
- Non-human readable json (so effectively less data) takes 90 seconds!

If tested all my endpoints and even small results take double time (when compacted) (40 ms process time becomes 80 ms), but the larger the response, the time to process the response seems to explode somehow.

Now the strange observations:

- I've tried both requests with Curl and both response are shown in somewhat the same time (roughly 3 seconds), to be complete this is the Curl command (with parameter active):
   curl --header "Accept: application/json" --compressed --header "Accept-Language: en" --header "Authorization: yadayada" --header "Connection: Keep-Alive" --user-agent "NetTalk 14.38" "https://127.0.0.1:8091/wsPurchases/ordersCoils?&readable=1"

- I've tried another set of requests against a nettalk 12.45 (production) server and then I see no (!!?) difference (so it's not only the client?)

I (no evidence) suspect compression might be at play here. So I also tried net.AcceptEncoding = 'plain' and net.AcceptEncoding = '', but this doesn't make any differenct (compact stays way slower).

Below are both (nettalk client) headers to be complete and I've attached two log files (one slow and one fast) that show the difference. And a screenshot where the difference occurs.

Problem is there no more data between the delay in the log file ...

I'm a little clueless about where to start searching now and/or what settings might influence this slowdown.

Any tips are most appreciated

Thanks in advance

Regards,
Ton

[AtoB]

I forgot to include the request headers:

Full http header for slow request/response (compact json):

GET /wsPurchases/ordersCoils HTTP/1.1
Accept: application/json
Accept-Language: en
Authorization: yadayada
Accept-Encoding: gzip
User-Agent: NetTalk 14.38
Host: 127.0.0.1:8091
Content-Length: 0
Connection: Keep-Alive

Full http header for fast request/response (human readable json)

GET /wsPurchases/ordersCoils?&readable=1 HTTP/1.1
Accept: application/json
Accept-Language: en
Authorization: yadayada
Accept-Encoding: gzip
User-Agent: NetTalk 14.38
Host: 127.0.0.1:8091
Content-Length: 0
Connection: Keep-Alive

(edit 27th aug ... also noticed the log files were not present)

[AtoB]

FOUND IT !

(It's NOT Nettalk !)

In net.pagereceived I've got this code:

  ?SomeControl{PROP:Text} = SELF.ThisPage.GetValue()

For some reason this thing goes haywire when I throw compacted json against it ... It also is not the "SELF.ThisPage.Getvalue()" itself, it's the assignment to the control ... have to dive into this a little deeper

[AtoB]

Additionally:

- turns out the production server had a much smaller payload returned than was in my mind (roughly 1/10th of the heavily tested payload), there was actually a 2/3 second delay too when the non-compacted json was to be displayed.
- I measure the duration of the whole process and this included the ?SomeControl{PROP:Text} statement too, that was a little misleading too (and made netwebclient suspect)

I guess text controls (at least in c10) really like linefeeds in the data to be displayed ...

Sorry for the inconvenience