public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Stoiko Ivanov <s.ivanov@proxmox.com>,
	Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pve-devel] [PATCH manager 1/1] api: journal: stream the journal data to the client
Date: Wed, 24 Nov 2021 18:46:04 +0100	[thread overview]
Message-ID: <1e36e64e-e8bc-940e-df9e-1079a353463c@proxmox.com> (raw)
In-Reply-To: <20211124183237.6e6fc40b@rosa.proxmox.com>

On 24.11.21 18:32, Stoiko Ivanov wrote:
> Huge thanks for addressing this so quickly and elegantly!
> 
> One question/nit:
> 
> On Wed, 24 Nov 2021 15:47:48 +0100
> Dominik Csapak <d.csapak@proxmox.com> wrote:
> 
>> instead of accumulating the whole output of 'mini-journalreader' in
>> the api call (this can be quite big), use the download mechanic of the
>> http-server to stream the output to the client.
>>
>> we lose some error handling possibilities, but we do not have
>> to allocate anything here, and since perl does not free memory after
>> allocating[0] this is our desired behaviour.
>>
>> to keep api compatiblitiy, we need to give the journalreader the '-j'
>> flag to let it output json.
>>
>> also tell the http server that the encoding is gzip and pipe
>> the output through it.
>>
>> 0: https://perldoc.perl.org/perlfaq3#How-can-I-free-an-array-or-hash-so-my-program-shrinks?
>>
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>>  PVE/API2/Nodes.pm | 22 ++++++++++++++--------
>>  1 file changed, 14 insertions(+), 8 deletions(-)
>>
>> diff --git a/PVE/API2/Nodes.pm b/PVE/API2/Nodes.pm
>> index 565cbccc..d57a1937 100644
>> --- a/PVE/API2/Nodes.pm
>> +++ b/PVE/API2/Nodes.pm
>> @@ -819,19 +819,25 @@ __PACKAGE__->register_method({
>>  	my $rpcenv = PVE::RPCEnvironment::get();
>>  	my $user = $rpcenv->get_user();
>>  
>> -	my $cmd = ["/usr/bin/mini-journalreader"];
>> +	my $cmd = ["/usr/bin/mini-journalreader", "-j"];
>>  	push @$cmd, '-n', $param->{lastentries} if $param->{lastentries};
>>  	push @$cmd, '-b', $param->{since} if $param->{since};
>>  	push @$cmd, '-e', $param->{until} if $param->{until};
>> -	push @$cmd, '-f', $param->{startcursor} if $param->{startcursor};
>> -	push @$cmd, '-t', $param->{endcursor} if $param->{endcursor};
>> +	push @$cmd, '-f', PVE::Tools::shellquote($param->{startcursor}) if $param->{startcursor};
>> +	push @$cmd, '-t', PVE::Tools::shellquote($param->{endcursor}) if $param->{endcursor};
>> +	push @$cmd, ' | gzip ';
> Not sure which would be more efficient - but the http-server does support
> gzipping the result from the API

It has no api result in that case, it just returns the open file handle and anyevent
can then stream that directly, see the response_stream method in PVE::APIServer::AnyEvent.

> might it make sense to let the worker do the gzip-encoding vs. forking
> gzip here?

contrary to our rust infra from PBS we do not have a streaming encoder directly in
the server that we can just layer in between, pve-http-server can currently only compress
if it has the whole response, and that's, which is what we want to avoid here.

The response method explicitly guards for the stream-an-fh case, AnyEvent.pm line 325:

if ($content && !$stream_fh) {
   # ...
   my $comp = Compress::Zlib::memGzip($content);

What we can do though is compress directly in the mini-journal reader, but that'll be
way easier once we rewrite in in rust (heh), as then we can reuse our existing
infrastructure to just layer that in-between.




  reply	other threads:[~2021-11-24 17:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-24 14:47 [pve-devel] [PATCH mini-journalreader/http-server/manager] optimize journal api cal Dominik Csapak
2021-11-24 14:47 ` [pve-devel] [PATCH mini-journalreader 1/1] add '-j' flag to output json Dominik Csapak
2021-11-24 17:17   ` [pve-devel] applied: " Thomas Lamprecht
2021-11-24 14:47 ` [pve-devel] [PATCH http-server 1/1] http-server: let the api call decide the content-encoding Dominik Csapak
2021-11-24 17:18   ` [pve-devel] applied: " Thomas Lamprecht
2021-11-24 14:47 ` [pve-devel] [PATCH manager 1/1] api: journal: stream the journal data to the client Dominik Csapak
2021-11-24 17:32   ` Stoiko Ivanov
2021-11-24 17:46     ` Thomas Lamprecht [this message]
2021-11-24 17:50       ` Stoiko Ivanov
2021-11-24 17:38   ` [pve-devel] applied: " Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1e36e64e-e8bc-940e-df9e-1079a353463c@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=s.ivanov@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal