Image renderer plugin: rendering horribly slow

[andig]

What would you like to be added:

Improved image renderer plugin performance with panel rendering below 1s.

Why is this needed:

I'm running Grafana on an Intel-powered Synology NAS. Export of panels als PNGs or hot-linking to such PNGs is horribly slow as the time to generate them is between 5 and 15 seconds for a single panel. This is pretty much unusable except for batching purposes.

While the box is not top-notch it has sufficient performance and 12GB of memory that suffices to run my other docker workload.

With rollout of the renderer plugin (#106) it would be great if the performance could be enhanced, e.g. by keeping a headless chrome running instead of starting per image.

[aknuds1]

Can you please rewrite the issue using our standard template? Thanks!

[andig]

We have the proper template now ;) Are there any plans for improving image render performance?

[aknuds1]

I don't know to be honest, not so involved with it yet personally.

[marefr]

@andig if you use remote rendering using docker instead of the plugin there's experimental/unofficial support for reusing a browser, see

grafana-image-renderer/src/app.ts

Lines 118 to 128 in 6ac82cf

	if (env['RENDERING_MODE']) {
	config.rendering.mode = env['RENDERING_MODE'] as string;
	}
	if (env['RENDERING_CLUSTERING_MODE']) {
	config.rendering.clustering.mode = env['RENDERING_CLUSTERING_MODE'] as string;
	}
	if (env['RENDERING_CLUSTERING_MAX_CONCURRENCY']) {
	config.rendering.clustering.maxConcurrency = parseInt(env['RENDERING_CLUSTERING_MAX_CONCURRENCY'] as string, 10);
	}

and https://github.com/grafana/grafana-image-renderer/blob/master/src/browser/index.ts#L13

[andig]

if you use remote rendering using docker instead of the plugin there's experimental/unofficial support for reusing a browser

Think I do ;):

grafana:
    container_name: grafana
    image: grafana/grafana
    ports:
    - 3000:3000
    environment:
    - GF_PATHS_CONFIG=/var/lib/grafana/grafana.ini
    - GF_RENDERING_SERVER_URL=http://renderer:8081/render
    - GF_RENDERING_CALLBACK_URL=http://grafana:3000/
    - GF_LOG_FILTERS=rendering:debug
    volumes:
    - /volume1/data/docker/grafana:/var/lib/grafana
    networks:
    - grafana
    restart: always

renderer:
    container_name: renderer
    image: grafana/grafana-image-renderer:latest
    ports:
    - 3001:8081
    # environment:
    # - RENDERING_MODE=reusable
    networks:
    - grafana
    restart: always

networks:
    grafana:

Now, as soon as I add the RENDERING_MODE I get this line in the docker log:

{"level":"info","message":"using reusable browser"}

Unfortunately, the image retrieval now ends in an HTTP 500 while it used to work before, no additional errors in the log.

[marefr]

@andig please do a docker pull grafana/grafana-image-renderer:latest to be sure you use the latest version. Would recommend explicitly use grafana/grafana-image-renderer:1.0.11.

What's the 500 details?

[marefr]

@andig If you're expecting rendering times below 1s I think you're out of luck. You can see a detailed break down of the load tests I did a while back: #84

[andig]

If you're expecting rendering times below 1s I think you're out of luck. You can see a detailed break down of the load tests I did a while back: #84

I constantly have >5s for a single user/image. That is pretty unusable.

please do a docker pull grafana/grafana-image-renderer:latest to be sure you use the latest version

No update (container recreated):

$ sudo docker pull grafana/grafana-image-renderer:latest
latest: Pulling from grafana/grafana-image-renderer
Digest: sha256:fb5a10bcb020e10b2ffebe9852474b98486e78903c32c89e8b2b520ec8caf06f
Status: Image is up to date for grafana/grafana-image-renderer:latest

It seems the request is working from command line and produces the expected PNG on disk:

❯ curl -v -I http://nas.fritz.box:3000/render/d-solo/YesC1MFiz/strom\?orgId\=1\&refresh\=5m\&theme\=light\&panelId\=8\&width\=1000\&height\=500\&tz\=Europe%2FBerlin
*   Trying 192.168.0.41...
* TCP_NODELAY set
* Connected to nas.fritz.box (192.168.0.41) port 3000 (#0)
> HEAD /render/d-solo/YesC1MFiz/strom?orgId=1&refresh=5m&theme=light&panelId=8&width=1000&height=500&tz=Europe%2FBerlin HTTP/1.1
> Host: nas.fritz.box:3000
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Accept-Ranges: bytes
Accept-Ranges: bytes
< Cache-Control: no-cache
Cache-Control: no-cache
< Content-Length: 89142
Content-Length: 89142
< Content-Type: image/png
Content-Type: image/png
< Expires: -1
Expires: -1
< Last-Modified: Mon, 30 Mar 2020 16:26:04 GMT
Last-Modified: Mon, 30 Mar 2020 16:26:04 GMT
< Pragma: no-cache
Pragma: no-cache
< Date: Mon, 30 Mar 2020 16:26:04 GMT
Date: Mon, 30 Mar 2020 16:26:04 GMT

< 
* Connection #0 to host nas.fritz.box left intact
* Closing connection 0

...but not from integrated into website (yet working without the parameter), copied from Safari dev tools:

Summary
URL: http://nas.fritz.box:3000/render/d-solo/YesC1MFiz/strom?orgId=1&refresh=5m&theme=light&panelId=8&width=1000&height=500&tz=Europe%2FBerlin
Status: 500 Internal Server Error
Source: Network
Address: 127.0.0.1:9000
Initiator: 
vue.min.js:6:44286


Request
GET /render/d-solo/YesC1MFiz/strom HTTP/1.1
Cookie: grafana_session=a29148b12740a23cc53157f4a6fef259; smid=CAeBibeqx6nPoMDbpos6uZGdKEqDlJtFroEUFZe9LzWPRsFWLzoViMOlwSWVkAR3ZsGW5NeWQYPMug3CHaXAOQ; stay_login=0
Accept: image/png,image/svg+xml,image/*;q=0.8,video/*;q=0.8,*/*;q=0.5
Accept-Encoding: gzip, deflate
Host: nas.fritz.box:3000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15
Accept-Language: en-us
Referer: http://nas.fritz.box:7070/
Connection: keep-alive
Proxy-Connection: keep-alive

Response
HTTP/1.1 500 Internal Server Error
Date: Mon, 30 Mar 2020 16:23:36 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Content-Length: 1722
Cache-Control: no-cache
Pragma: no-cache

Query String Parameters
orgId: 1
refresh: 5m
theme: light
panelId: 8
width: 1000
height: 500
tz: Europe/Berlin

Adding all the headers to curl works:

curl -v -I \
-H 'Cookie: grafana_session=a29148b12740a23cc53157f4a6fef259; smid=CAeBibeqx6nPoMDbpos6uZGdKEqDlJtFroEUFZe9LzWPRsFWLzoViMOlwSWVkAR3ZsGW5NeWQYPMug3CHaXAOQ; stay_login=0' \
-H 'Accept: image/png,image/svg+xml,image/*;q=0.8,video/*;q=0.8,*/*;q=0.5' \
-H 'Accept-Encoding: gzip, deflate' \
-H 'Host: nas.fritz.box:3000' \
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15' \
-H 'Accept-Language: en-us' \
-H 'Referer: http://nas.fritz.box:7070/' \
-H 'Connection: keep-alive' \
-H 'Proxy-Connection: keep-alive' \
http://nas.fritz.box:3000/render/d-solo/YesC1MFiz/strom\?orgId\=1\&refresh\=5m\&theme\=light\&panelId\=8\&width\=1000\&height\=500\&tz\=Europe%2FBerlin

I can understand it you want to treat this as individual issue. Would however be happy to turn on any logging that might indicate cause of the 500 from server side.

[andig]

Digest: sha256:fb5a10bcb020e10b2ffebe9852474b98486e78903c32c89e8b2b520ec8caf06f

I‘ve checked that‘s the tag of 1.0.11 (https://hub.docker.com/r/grafana/grafana-image-renderer/tags)

[andig]

I have also added

grafana-image-renderer/src/app.ts

Line 131 in 23f90be

config.rendering.verboseLogging = env['RENDERING_VERBOSE_LOGGING'] === 'true';

now on the renderer container but cannot see anything more in the renderer‘s log. Funnily the HTTP 500s are gone too, performance is still bad. I must admit that I‘m no longer sure that the requests are really passed down to the rendering server: I‘m hitting grafana first with the config given above.

Verified this doubt using the grafana logs:

t=2020-03-30T20:14:33+0000 lvl=info msg="Backend rendering via external http server" logger=rendering renderer=http
t=2020-03-30T20:14:34+0000 lvl=info msg="Initializing Stream Manager"
t=2020-03-30T20:14:34+0000 lvl=info msg="HTTP Server Listen" logger=http.server address=[::]:3000 protocol=http subUrl= socket=
t=2020-03-30T20:14:56+0000 lvl=info msg=Rendering logger=rendering renderer=http path="d-solo/YesC1MFiz/strom?orgId=1&refresh=5m&theme=light&panelId=8&width=1000&height=500&tz=Europe%2FBerlin"

[andig]

I've meanwhile found the LOG_LEVEL setting too and have an idea what might be the cause of the HTTP 500:

TypeError: Cannot read property 'createIncognitoBrowserContext' of undefined

{"level":"info","message":"using reusable browser"}
{"level":"info","message":"Using chromeBin /usr/bin/chromium-browser"}
{"level":"info","message":"HTTP Server started, listening at http://localhost:8081"}
{"url":"http://grafana:3000/d-solo/YesC1MFiz/strom?orgId=1&refresh=5m&theme=light&panelId=8&width=1000&height=500&tz=Europe%2FBerlin&render=1","level":"debug","message":"Render request received"}
{"url":"/render?domain=grafana&encoding=&height=500&renderKey=ARm6UP4IqVRR1p8X2O6FZEwV3pKxB9BR&timeout=60&timezone=Europe%2FBerlin&url=http%3A%2F%2Fgrafana%3A3000%2Fd-solo%2FYesC1MFiz%2Fstrom%3ForgId%3D1%26refresh%3D5m%26theme%3Dlight%26panelId%3D8%26width%3D1000%26height%3D500%26tz%3DEurope%252FBerlin%26render%3D1&width=1000","stack":"TypeError: Cannot read property 'createIncognitoBrowserContext' of undefined\n    at ReusableBrowser.<anonymous> (/usr/src/app/build/browser/reusable.js:31:46)\n    at Generator.next (<anonymous>)\n    at /usr/src/app/build/browser/reusable.js:7:71\n    at new Promise (<anonymous>)\n    at __awaiter (/usr/src/app/build/browser/reusable.js:3:12)\n    at ReusableBrowser.render (/usr/src/app/build/browser/reusable.js:26:16)\n    at HttpServer.<anonymous> (/usr/src/app/build/service/http-server.js:40:47)\n    at Generator.next (<anonymous>)\n    at /usr/src/app/build/service/http-server.js:7:71\n    at new Promise (<anonymous>)","level":"error","message":"Request failed"}
{"url":"http://grafana:3000/d-solo/YesC1MFiz/strom?orgId=1&refresh=5m&theme=light&panelId=8&width=1000&height=500&tz=Europe%2FBerlin&render=1","level":"debug","message":"Connection closed"}
{"message":"::ffff:172.21.0.3 - - [31/Mar/2020:06:18:49 +0000] \"GET /render?domain=grafana&encoding=&height=500&renderKey=ARm6UP4IqVRR1p8X2O6FZEwV3pKxB9BR&timeout=60&timezone=Europe%2FBerlin&url=http%3A%2F%2Fgrafana%3A3000%2Fd-solo%2FYesC1MFiz%2Fstrom%3ForgId%3D1%26refresh%3D5m%26theme%3Dlight%26panelId%3D8%26width%3D1000%26height%3D500%26tz%3DEurope%252FBerlin%26render%3D1&width=1000 HTTP/1.1\" 500 96 \"-\" \"Grafana/6.7.1\"\n","level":"error"}

Please let me know if there's anything else I could do in terms of diagnostics.

It seems this is happening when invoking the renderer before the browser has actually started. I can now reproducibly generate panels with the reusable browser.

Unfortunately, it is still as slow as before. Rendering takes more than 5s even for a single panel.

[marefr]

Chromium/puppeteer performance in docker is a tricky thing. I did read up on this article and this earlier and tried some of the suggestions, but didn't make that big of a difference according to my tests.

A big difference with browserless article and Grafana image rendering is that it's tricky to cache assets since it can be a potential security issue due to cookie is being sent with request to Grafana. But a potential improvement could be to use an HTTP header instead.

Currently, we have no plans focusing on improving performance. But if anyone have experience optimizing puppeteer/chromium/chrome performance any information/help would be very valuable.

You can enable metrics and scrape /metrics using Prometeheus to be able to measure performance over time. You can find some additional information looking at the load test setup:

• https://github.com/grafana/grafana-image-renderer/tree/master/devenv/docker/ha
• https://github.com/grafana/grafana-image-renderer/tree/master/devenv/loadtest

HA setup includes cadvisor to gather memory and CPU metrics and more.

You can try the RENDERING_MODE=clustered with RENDERING_CLUSTERING_MAX_CONCURRENCY=5.

You can try grafana/grafana-image-renderer:1.0.12-beta1 with the following environment variable and see if you see any difference in performance:
RENDERING_ARGS=--no-sandbox,--disable-setuid-sandbox,--disable-dev-shm-usage,--disable-accelerated-2d-canvas,--disable-gpu,--window-size=1920x1080

Here's a reference to all command line switches for Chromium that can be provided through environment variable RENDERING_ARGS: https://peter.sh/experiments/chromium-command-line-switches/

You may also want to experiment with the Dockerfile and build a custom one in case that makes a different.

[ghost]

I have an Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz here as a single server. And phantomjs was acceptable fast. But the new image rendering plugin takes ages to render something

[andig]

But the new image rendering plugin takes ages to render something

Could you share how long it takes for you? My platform may not be typical, but I can share that- even plugin is used and only a single image rendered- rendering times are >10s.

@marefr that said, tuning would not be about clustering or concurrency but about single image render time when system idle.

[ghost]

Could you share how long it takes for you? My platform may not be typical, but I can share that- even plugin is used and only a single image rendered- rendering times are >10s.

~6 seconds for my system for a single image. But the webpages usually include 4 or more images

[phil-or]

~6 seconds for my system for a single image. But the webpages usually include 4 or more images

We use a plugin for our icinga2 monitoring environment icingaweb2-module-grafana which is also dependent on the image rendering. So with the new image-renderer it takes also ~5-10 seconds for a single image on the webpage. As in the first post mentioned, faster image rendering would be desirable.

[dbuelow]

We use the same Icinga2 setup and it took about 4s to render the image.

[fl0wx]

+1 from me. We also use the same Icinga2 setup and about ~3 secs to render.

also tried the clustered and reusable mode. Both didnt increased the performance. The Server is bare metal and has enough performance (64GB RAM, 16 Core E3 CPU)

Performance before we used this plugin was way higher (with grafana integrated rendering)

[kunsjef]

Sorry to bombard this thread, but same problem here.

We have 4 different Icinga2 installations all with Grafana integrated. After having to use the new renderer the performance is really bad compared to what it was before.

Two of our installations are on bare metal and two are VM's. One of the bare metals is a high performance server with a fresh install of Icinga2/Grafana with only self checks enabled. The performance is sluggish on all installations.

[dfrise]

We also use the same Icinga2 setup and about ~3 secs to render.
With grafana-6.7.3 and included PhantomJS renderer this was ~1 sec to render.
We also run Icinga2 on a bare metal RHEL7 machine with 64GB RAM and 2xIntel Xeon E5-2680v4 14 cores 2.4GHz
We decided to stick to grafana-6.7.3 but this is not a long term solution

[andig]

Sorry to bombard this thread, but same problem here.

I appreciate the feedback as it shows that the performance problems are not specific to my low-end platform.

[fyang13]

We are seeing similar issue here, in Grafana 6.x, the average rendering latency is 3s, after Grafana v7 with remote image renderer plugin, the average went up to 5+s consistently.
We are not seeing high cpu/memory usage for either Grafana server or Remote Image renderer running in Docker container.

[IPB-DevOps]

We can confirm this issue, after updating our icingaweb2 plugin with grafana 7 and the grafana-image-renderer, the render time of images increase by 4 or 5 times.

Has Anyone suggestions for options in the grafana.ini to speed up the process?

[lukaslusto]

Same here - Grafana 6.x was on 5s on average which didn't pass our UAT, upgrading to Grafana 7.x with remote image renderer plugin only increased rendering time to 6-7s on average (both running in docker container)

[MarcusCaepio]

Same here,
I just upgraded grafana to version 7 on one of our 2 Icinga2 masters. Both Ubuntu 18.04, Icingaweb2, Grafana, Icingaweb2-Grafana Module installed.
Beside the fact, that I had to install very much additional packages (see Mikesch-mp/icingaweb2-module-grafana#248 ) The rendering in Icingaweb2 is very low. Clicking a service takes 5 seconds, before it appears. On grafana 6.8 it took around 1 second. I just restored my VM Snapshot to grafana 6.8

[andig]

@marefr seems there are a number of reports of actual performance degradation now, both on high-end platforms and concerning single image rendering (instead of performance under load). My understanding was that the render plugin should come with a pre-booted browser and hence have the potential to increase performance as bootstrap efforts are eliminated. The opposite seems to be the effect.

Is there any detail/ insights we could provide to take this issue further?

[marefr]

I'm still referring to #124 (comment). I understand you experience performance degradation, but since we don't it's very hard to investigate/do anything from out side. Help from you/the community is needed.

[107142]

Direct rendering of single image takes around 3-4 sec in dockerized Grafana (VMware, 8vCPU, 16GB RAM) with the new image renderer compared to 1-2 sec with PhantomJS. That is unbearably slow.

I have tried every possible switch provided in this thread and Puppeteer docs, nothing seems to help.
While I realize PhanotmJS was deprecated and the change therefore necessary, it's difficult not to see it as downgrade and even more difficult to explain to my users why is the newer and shinier version "worse".

[MarcusCaepio]

Anything new here? Would be very sad, if this issue will be ignored....

[IPB-DevOps]

We need to speed up the process by minimum 2 times, 3-4 seconds are to slow compared to 1-2 seconds in previous versions.
Any suggestions?

Reproduce:

1. create a graph panel
2. click share => "Direct link rendered image"
   response time will be 3 - 4 seconds (on any time range)

[lazyfrosch]

I see two approaches for a better usage:

1. Create a way to render a graph as SVG, so you won't have to create a screenshot, the resulting SVG can then be downloaded without the use of an external renderer. Other tools could be used to convert SVG to other image formats

2. Don't use images to embed into other views, embed an iframe, with the minimal content used to render the image

For any improvement, nobody should expect that it just will be done. Maybe someone can look into it and provide an implementation.

The cause of the current problem is due to being forced to replace PhantomJS by a supported component, Chromium, which is slower in this way of using it.

[fl0wx]

Any update on that issue? Rendering via Icinga2 Web is still horribly slow and havent found any optimization

[xf-]

Any update on that issue? Rendering via Icinga2 Web is still horribly slow and havent found any optimization

The issue is massive amount of JS (like FE request - single panel waiting until everything is loaded). You can change some stuff, but will not resolve major part of the loading time. It loads multiple JS Frameworks and runs them.

[fl0wx]

so are there any alternatives or possibilities to improve the speed a bit?

[MarcusCaepio]

This issue is open for over 8 months now. I am really sad, that nothing is happening here. I am still stuck on Grafana 6, because I cannot expect my users to wait 10 seconds for a service overview with a grafana panel in Icingaweb2 :(

[jeroenst]

Tried image renderer today, it is horrible slow (takes about 5s before image is displayed), so I can't use it.

[torkelo]

I tried to explore a way to avoid full page reloads between renders, here is a very simple POC #199

The first image takes the normal amount of time: 2-3 seconds
After that, the image renderings take about 200 - 300ms (assuming the panel queries are very fast)

The POC needs a lot more work the be production viable.

If anyone want to help explore how to turn this POC into something more production viable, help is appreciated

[MarcusCaepio]

@torkelo
I am very happy, that you are investigating this problem. Looking forward to a good solution for the use case of us all, who are currently struggling with the update to 7 :)

[tomabg]

Are there any news here?
After update of Centos we are also forced to use the new image renderer in icinga2 which is very slow:-(

[107142]

If you are using Icinga with Grafana plugin you may consider just using iFrame and directly pass the graph from GF inside the Icingaweb.

There are numerous ways to reasonably secure the access. I opted for strictly defined CSP and Single-Sign-On.
While hardly a proper solution it does make for a very smooth experience from user's perspective, graphs are rendered pretty much immediately and support all the bells and whistles of a native Grafana dashboard, which is nice. Both Icinga and Grafana support SSO. Not ideal, but it beats 5 sec waiting times IMHO.
I've had it in production like this over a half a year and it's been a very smooth sailing.

Anyway I think it's unrealistic to expect a solution to this from an open source with limited resources.

[tomabg]

Anyway I think it's unrealistic to expect a solution to this from an open source with limited resources.

also this would be an awnser maybe...so my question is: Is there a chance to improve performance in future?

btw. in my case it needs 3.5 seconds to load the graph.....under 2 seconds would be imho acceptable

[tomabg]

If you are using Icinga with Grafana plugin you may consider just using iFrame and directly pass the graph from GF inside the Icingaweb.

Do you have a howto for this change please?

[MarcusCaepio]

Using iFrame is not a solution, when you have restrictions, who can use grafana and who not. When a user is allowed to see things in Icingaweb2, it does not mean, he is also allowed to use grafana itself, beside the page refresh will be distracted:

In Iframe mode you have the full power of Grafana features like mouse over tooltip. Pro: All features from Grafana enabled. Fast page rendering. Contra: Less secure, page refresh from Icingaweb2 will be distracting! Needs auth.anonymous enabled in Grafana.

[tomabg]

it's too bad that there seems no progress on this important issue :-(

[xf-]

An iFrame is not a good solution.
iFrame is often slower as a server and the only advantage is the cache compared to chromium on server without any cache on the server. If you access it form a smartphone the cpu power will be less as on server and causes more issues.
Also it is around 2.8 MB (10.1 uncompressed) instead of < 100kb for the image.

You just moving the problem to an unreliable resource depending on connection (speed and latency) and unkown cpu power.

[107142]

An iFrame is not a good solution.
iFrame is often slower as a server and the only advantage is the cache compared to chromium on server without any cache on the server. If you access it form a smartphone the cpu power will be less as on server and causes more issues.
Also it is around 2.8 MB (10.1 uncompressed) instead of < 100kb for the image.

You just moving the problem to an unreliable resource depending on connection (speed and latency) and unkown cpu power.

Never claimed it is a solution. It's something you may consider depending on your setup and possibilities. Smartphones are not relevant for us.
It works well with OIDC proxy in front of it, at-least until something better comes up. Obviously it won't work if fine user control for both apps is important to you or you have other concerns (like bandwidth and CPU is for you).

I'd have thought it's quite obvious and does not need to be spelled out that it's something others may consider and not a proper solution.

[xf-]

The server is normally as fast as the client, if the server has a similar speed. Only difference is you have no cache & also you see something loading. If you put an spinner/animation it has the same effect. If you need multiple graphs you can use the kiosk mode.

Also a Pull Request is in WIP, you could patch it yourself and help testing. Basically reuse the chrome instance and don't restart the JS horror of Grafana again. for a single graph.

[uebenes]

I can confirm, in Grafana 7.5.9, it's still every slow. I havn't checked it in Grafana 8.

[n3k232]

In Grafana 8.0.5 the Problem still exists, and i found out it gets even worse if i activate SSL in the Grafana configuration. It now take aber 20 to 25 seconds to render an Image if SSL is activated.

[uebenes]

I have tried it out over the direct installation of the plugin and also with the image renderer as separate docker container: but both is slow (about 5s)

[xf-]

@uebenes of course it is slow. Something will be referenced, like the WIP Pull Request on 10. Dec 2020. The solution complex. Always use the same instance with reload, so no init from all that JS stuff OR create a template for the renderer without unused JS Stuff (only us the needed stuff). In a perfect world, both things were implemented.
If you test chromium to take a screenshot from a website, it is really fast.

[n3k232]

UPDATE: our rendering was awfully slow ~ 30sec per Image, now we found out, that since we used a proxy for our grafana-server, the grafana-server it self could not connect to our CRL, now we added the crl to the no-proxy in the /etc/sysconfig/grafana-server configuration and our rendring is now much faster ~ 5 seconds.

[ilyesAj]

is there any upadates on this subject, we're running on grafana 7.3.1 and we're hitting 500 error since the rendering is too slow

{"level":"error","message":"Request failed","stack":"TimeoutError: Navigation timeout of 60000 ms exceeded\n    at /usr/src/app/node_modules/puppeteer/lib/cjs/puppeteer/common/LifecycleWatcher.js:106:111\n    at runNextTicks (internal/process/task_queues.js:60:5)\n    at listOnTimeout (internal/timers.js:526:9)\n    at processTimers (internal/timers.js:500:7)