Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2014-06

CustHttpApp and HP httperf tool

21 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

silvioprog

Hello,

I'm testing the CustHttpApp unit, and I found one error. See the httperf logs below:

CGI (tested with FastCGI and it worked succefuly too): -------
httperf --client=0/1 --server=127.0.0.1 --port=80
--uri=/cgi-bin/project1.cgi --rate=100 --send-buffer=4096 --recv-buffer=4096 --num-conns=1 --num-calls=2
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
Maximum connect burst length: 0

Total: connections 1 requests 2 replies 2 test-duration 0.006 s

Connection rate: 178.3 conn/s (5.6 ms/conn, <=1 concurrent connections) Connection time [ms]: min 5.6 avg 5.6 max 5.6 median 5.5 stddev 0.0 Connection time [ms]: connect 0.1
Connection length [replies/conn]: 2.000

Request rate: 356.6 req/s (2.8 ms/req)
Request size [B]: 77.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples) Reply time [ms]: response 2.8 transfer 0.0
Reply size [B]: header 191.0 content 11.0 footer 0.0 (total 202.0) Reply status: 1xx=0 2xx=2 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.00 system 0.01 (user 0.0% system 99.5% total 99.5%) Net I/O: 97.2 KB/s (0.8*10^6 bps)

Errors: *total 0* client-timo 0 socket-timo 0 connrefused 0 connreset 0 Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0 -------

CustHttpApp:
-------
httperf --client=0/1 --server=127.0.0.1 --port=8080 --uri=/ --rate=100 --send-buffer=4096 --recv-buffer=4096 --num-conns=1 --num-calls=2 httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
Maximum connect burst length: 0

Total: connections 1 requests 2 replies 1 test-duration 0.002 s

Connection rate: 449.2 conn/s (2.2 ms/conn, <=1 concurrent connections) Connection time [ms]: min 2.2 avg 2.2 max 2.2 median 2.5 stddev 0.0 Connection time [ms]: connect 0.2
Connection length [replies/conn]: 1.000

Request rate: 898.4 req/s (1.1 ms/req)
Request size [B]: 62.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples) Reply time [ms]: response 1.8 transfer 0.0
Reply size [B]: header 80.0 content 11.0 footer 0.0 (total 91.0) Reply status: 1xx=0 2xx=1 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.00 system 0.00 (user 93.1% system 0.0% total 93.1%) Net I/O: 94.3 KB/s (0.8*10^6 bps)

Errors: *total 1* client-timo 0 socket-timo 0 connrefused 0 connreset 1 Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0 -------

This is the code used in CustHttpApp test:

-------
program project1;
{$mode objfpc}{$H+}

uses
cthreads,
custhttpapp,
custweb,

  HTTPDefs;
type
  { TMyHttpApplication }
  TMyHttpApplication = class(TCustomHttpApplication)
  protected
    function InitializeWebHandler: TWebHandler; override;
  end;
  { TMyHttpServerHandler }
  TMyHttpServerHandler = class(TFPHttpServerHandler)
  public
    procedure HandleRequest(ARequest: TRequest; AResponse: TResponse);
override;
  end;
  function TMyHttpApplication.InitializeWebHandler: TWebHandler;
  begin
    Result := TMyHttpServerHandler.Create(Self);
  end;
  procedure TMyHttpServerHandler.HandleRequest(ARequest: TRequest;
    AResponse: TResponse);
  begin
    AResponse.Contents.Text := 'testing it';
  end;
begin
  with TMyHttpApplication.Create(nil) do
    try
      Initialize;
      Port := 8080;
      Threaded := True;
      Run;
    finally
      Free;
    end;
end.
-------

Can you test it please?

My environment:

Lazarus 1.2.2 r44765 FPC 2.6.4 x86_64-linux-gtk 2

Silvio Clécio My public projects - github.com/silvioprog

Reply by email

Michael Van Canneyt
to silvioprog
silvioprog wrote
Hello, I'm testing the CustHttpApp unit, and I found one error. See the httperf logs below:

The http server does not support keeping the connection open.

Michael.

Reply by email

silvioprog
to Michael Van Canneyt

2014-06-06 13:17 GMT-03:00 Michael Van Canneyt :

Show quoted text 11 lines
On Fri, 6 Jun 2014, silvioprog wrote: > Hello, > I'm testing the CustHttpApp unit, and I found one error. See the httperf > logs below: > The http server does not support keeping the connection open. Michael.

:-(

Silvio Clécio My public projects - github.com/silvioprog

Reply by email

Michael Van Canneyt
to silvioprog
silvioprog wrote 12 lines
2014-06-06 13:17 GMT-03:00 Michael Van Canneyt : On Fri, 6 Jun 2014, silvioprog wrote: Hello, I'm testing the CustHttpApp unit, and I found one error. See the httperf logs below: The http server does not support keeping the connection open. Michael. :-(

It is on my TODO list, but with very low priority.

Michael.

Reply by email

silvioprog
to Michael Van Canneyt

2014-06-07 4:54 GMT-03:00 Michael Van Canneyt :

Show quoted text 19 lines
On Fri, 6 Jun 2014, silvioprog wrote: > 2014-06-06 13:17 GMT-03:00 Michael Van Canneyt : > On Fri, 6 Jun 2014, silvioprog wrote: > Hello, > I'm testing the CustHttpApp unit, and I found one error. See > the httperf logs below: > > > The http server does not support keeping the connection open. > > Michael. > > > :-( > It is on my TODO list, but with very low priority.

Free Pascal surprises me more and more! :-)

Silvio Clécio My public projects - github.com/silvioprog

Reply by email

Michael Schnell
to silvioprog: 2014-06-06 13:17 GMT-03:00 Michael Van Canneyt : :-( Silvio Clécio My public projects -…
silvioprog wrote 7 lines
The http server does not support keeping the connection open. Michael. :-(

I recently learned (but did not do any testing yet) that "Websocket" is the current way to go instead of keeping an http socket open.

If course the browser, the server, and any proxy in between needs to support this but I was told that his is supposed to usually to be in place.

-Michael

Reply by email

Michael Van Canneyt
to Michael Schnell
Michael Schnell wrote 9 lines
On 06/06/2014 07:48 PM, silvioprog wrote: The http server does not support keeping the connection open. Michael. :-( I recently learned (but did not do any testing yet) that "Websocket" is the current way to go instead of keeping an http socket open.

This is not correct. The purpose of a websocket is entirely different, these are not interchangeable technologies. A websocket is not even the HTTP protocol.

If course the browser, the server, and any proxy in between needs to support this but I was told that his is supposed to usually to be in place.

This is also not correct. I have had many problems deploying a websockets based program.

Michael.

Reply by email

Michael Schnell
to Michael Van Canneyt
Michael Van Canneyt wrote
The purpose of a websocket is entirely different, these are not interchangeable technologies. A websocket is not even the HTTP protocol.

I do know this. I was told that websocket is a kind of successor technology for the replacement of not very "safe" methods like "comet" that rely on kept-open http sockets.

Show quoted text 8 lines
> If course the browser, the server, and any proxy in between needs to > support this but I was told that his is supposed to usually to be in > place. This is also not correct. I have had many problems deploying a websockets based program.

I see. So what I have been told by a websocket advocate (who indeed erroneously claimed that websocket is a HTTP protocol and proxies would not need to acknowledge such a new protocol, calling me a fool for doubting this), seems to be wrong :-( .

-Michael

Reply by email

Michael Van Canneyt
to Michael Schnell
Michael Schnell wrote 8 lines
On 06/10/2014 10:22 AM, Michael Van Canneyt wrote: > > The purpose of a websocket is entirely different, these are not > interchangeable technologies. > A websocket is not even the HTTP protocol. I do know this. I was told that websocket is a kind of successor technology for the replacement of not very "safe" methods like "comet" that rely on kept-open http sockets.

Utter nonsense.

Websockets are good when the server needs to push similar data at high speed, no more, no less.

When different request for different kinds of data need to be fetched, HTTP 1.1, with its option for keeping the connection open, is more suitable.

Show quoted text 11 lines
>> If course the browser, the server, and any proxy in between needs to >> support this but I was told that his is supposed to usually to be in >> place. > > This is also not correct. I have had many problems deploying a websockets > based program. > I see. So what I have been told by a websocket advocate (who indeed erroneously claimed that websocket is a HTTP protocol and proxies would not need to acknowledge such a new protocol, calling me a fool for doubting this), seems to be wrong :-( .

Very wrong. Always distrust advocates :)

Michael.

Reply by email

Michael Schnell
to Michael Van Canneyt
Michael Van Canneyt wrote
Websockets are good when the server needs to push similar data at high speed, no more, no less.

Hmm.
I understand that websocket is a TCP/IP protocol that (after being opened due to commands communicated via HTTP) stays open and hence provides a pipe that both sites can push data in.

This potentially might be suitable to allow the server (i.e. the fast-cgi program) to send state-messages to the browser (e.g.in order to create a web-GUI).

-Michael

Reply by email

Michael Van Canneyt
to Michael Schnell
Michael Schnell wrote 9 lines
On 06/10/2014 10:38 AM, Michael Van Canneyt wrote: > > Websockets are good when the server needs to push similar data at high > speed, no more, no less. > Hmm. I understand that websocket is a TCP/IP protocol that (after being opened due to commands communicated via HTTP) stays open and hence provides a pipe that both sites can push data in.

More or less, yes.

This potentially might be suitable to allow the server (i.e. the fast-cgi program) to send state-messages to the browser (e.g.in order to create a web-GUI).

Check e.g. the "leap motion" device.

It uses a websocket to stream the skeleton tracking data to whoever wants it. This I consider a good example of the use of a websocket.

IMO a web-gui that needs a stateful server part is suicide (it doesn't scale at all), and therefor I consider that a bad example.

Michael.

Reply by email

Michael Schnell
to Michael Van Canneyt
Michael Van Canneyt wrote 6 lines
IMO a web-gui that needs a stateful server part is suicide (it doesn't scale at all), and therefor I consider that a bad example.

I see your point, but this would prevent any attempt to do a web-interface that can be designed via the Lazarus gui designer and hence would-be cgi programs to be tested locally with "normal" Lazarus means, and allow for "easy"porting Lazarus (and Delphi) programs to be cgi's.

("Technically" such a "stateful" web GUI widget type could be crafted based on the "customdrawn" widget type and a java script / HTML5 library that draws the basic widgets.)

IMOH, such a tool would be a great plus for Lazarus to offer, even if of course the look of such a thingy within the browser would not completely match the look on a "normal" desktop and certain controls are not available.
That is why I (at some other place) discussed websocktes.

-Michael

Reply by email

Michael Van Canneyt
to Michael Schnell
Michael Schnell wrote 12 lines
On 06/10/2014 11:47 AM, Michael Van Canneyt wrote: > > > IMO a web-gui that needs a stateful server part is suicide (it doesn't > scale at all), > and therefor I consider that a bad example. > I see your point, but this would prevent any attempt to do a web-interface that can be designed via the Lazarus gui designer and hence would-be cgi programs to be tested locally with "normal" Lazarus means, and allow for "easy"porting Lazarus (and Delphi) programs to be cgi's.

This is simply not correct. See the non-lcl widget support. Joost van der Sluis uses it for HTML and iOS design.

I wrote an article about it many years back when it was first implemented. Indeed, I requested (along with others) this functionality exactly to be able to do what you claim "would be prevented".

Michael.

Reply by email

Michael Schnell
to Michael Van Canneyt
Michael Van Canneyt wrote
This is simply not correct.

Sorry. I don't understand.
I feel that an LCL based GUI is "stateful serve" and hence what you say is suicidal.

See the non-lcl widget support.

Of course it is possible to do widgets without support of the lCL infrastructure, using some external GUI designer (AFAIK, FPGUI can do this, as well). But I don't see why this proves that it would not be beneficial to use the nice stuff that is already in place for Desktop purpose.

I wrote an article about it many years back

Could you point me to same ?

Thanks,
-Michael

Reply by email

Michael Van Canneyt
to Michael Schnell
Michael Schnell wrote 7 lines
On 06/10/2014 01:02 PM, Michael Van Canneyt wrote: > > > This is simply not correct. Sorry. I don't understand. I feel that an LCL based GUI is "stateful serve" and hence what you say is suicidal.

I didn't speak about LCL based. I do speak about designing the GUI in Lazarus. (in time with translation of pascal code to Javascript)

Show quoted text 6 lines
> See the non-lcl widget support. Of course it is possible to do widgets without support of the lCL infrastructure, using some external GUI designer (AFAIK, FPGUI can do this, as well). But I don't see why this proves that it would not be beneficial to use the nice stuff that is already in place for Desktop purpose.

Because this nice stuff does not translate to web.

> I wrote an article about it many years back Could you point me to same ?

http://www.freepascal.org/~michael/articles/#nonlcl

Michael.

Reply by email

Michael Schnell
to Michael Van Canneyt
Michael Van Canneyt wrote
Because this nice stuff does not translate to web.

Of course not 1:1.

And of course not easy to do (the "ExtPascal" project did try this some years ago and AFAIK it is on a halt since long)

But my QNAP NAS at home features a Web GUI that has a look and feel very similar to an LCL based GUI (I seem to remember that they have a demo on their website).

Thanks !
I'll take a look

-Michael

Reply by email

Reinier Olislagers
to Michael Schnell
Michael Schnell wrote 12 lines
On 06/10/2014 01:19 PM, Michael Van Canneyt wrote: > > Because this nice stuff does not translate to web. Of course not 1:1. And of course not easy to do (the "ExtPascal" project did try this some years ago and AFAIK it is on a halt since long) But my QNAP NAS at home features a Web GUI that has a look and feel very similar to an LCL based GUI (I seem to remember that they have a demo on their website).

I'm having a feeling of deja-vu all over again....- Didn't this exact same discussion not happen some months back?
@Michael Schnell: how is the non GUI event stuff coming along?

Reply by email

Michael Schnell
to Reinier Olislagers
Reinier Olislagers wrote
Didn't this exact same discussion not happen some months back?

Yep. here or somewhere else.

IMHO, as the computing world gets more "client/server" centric, the Web GUI issue gets increasingly interesting when deciding which programming environment to chose for any project promising to be more that a one-shot thingy.

@Michael Schnell: how is the non GUI event stuff coming along?

As written in the other thread, it does work nicely using the current (updated) version of EpikTimer (or alternatively using some preliminary stuff done internally).

To be decently useful I think updating EpikTimer to use vDSO is necessary. I'm going to test this ASAP.

In the other thread I asked if anybody would like to test it and send a list of lacking features. As nobody answered, I understand Thai I am the only one interested in this stuff.

I am positive that I'll be able to do some usable code but in fact I have no clue how to have it integrated in the LCL so that it can be used by selecting a WidgetType variable called -say- "ActiveNoGui".

But just for my own sake I don't know if this is worth bothering the "powers" with my request for help.

-Michael

Reply by email

Michael Schnell
to Reinier Olislagers: I'm having a feeling of deja-vu all over again....- Didn't this exact same discussion not…
Reinier Olislagers wrote
how is the non GUI event stuff coming along

BTW: obviously you did notice that the issues are connected: doing a "stateful server" in a CGI does need the non GUI event stuff.

I did not research how "CustomDrawn" handles events (originated by the GUI and originated by timers and threads). But if "CustomDrawn" would be used as a basis for a Web GUI (provided that this turns out to make any sense), we would need something like the said "non GUI event stuff" in the background: "GUI" events are generated by TCP/IP receive events (to be handled in the main thread, and supposedly fired in a thread that waits on a blocking TCP/IP socket), other main thread events are fired by Timers (I just implemented that) or by standard worker TThreads (already supported by the RTL).

-Michael

Reply by email

Reinier Olislagers
to Michael Schnell: Yep. here or somewhere else. IMHO, as the computing world gets more "client/server"…
Michael Schnell wrote 6 lines
On 06/10/2014 01:59 PM, Reinier Olislagers wrote: > @Michael Schnell: how is the non GUI event stuff coming along? As written in the other thread, it does work nicely using the current (updated) version of EpikTimer (or alternatively using some preliminary stuff done internally).

Ok.

In the other thread I asked if anybody would like to test it and send a list of lacking features. As nobody answered, I understand Thai I am the only one interested in this stuff.

Why not put your code on a public repository and post a link? That would probably help give more exposure...

I am positive that I'll be able to do some usable code but in fact I have no clue how to have it integrated in the LCL so that it can be used by selecting a WidgetType variable called -say- "ActiveNoGui".

I thought that was the entire point of your code but I may be mistaken?

But just for my own sake I don't know if this is worth bothering the "powers" with my request for help.

Well, as you bring up your proposed ActiveNoGui as a solution many times in mailing list threads it looks like you're convinced it would not only be helpful for yourself but for others, too... ;)

Reply by email

Michael Schnell
to Reinier Olislagers
Reinier Olislagers wrote
I thought that was the entire point of your code but I may be mistaken?

Yep (once the code in fact works to my satisfaction).

n fact I currently don't have any project in favor of myself, hence - besides curiosity - my intention is to enhance Lazarus.

.. it looks like you're convinced it would not only be helpful for yourself but for others, too... ;)

Of course. (otherwise I would not discuss the issue).

In fact, very recently there was a post in a mailing list and I answered to it. But no further comment was given.

-Michael

Reply by email