I have a problem with slow charts. I am using both rrd (with everyminute strategy) and db4o + default chart provider (just use Chart in sitemap). All of charts which I want to display on GUI (it doesn’t matter from which persistence or quantity of items) , when I enter it I must wait 10-20 seconds until they will appear .
It is on LAN, on VPN usually I got that image is broken and after few times I can see it.
What should I check ? Where can be problem located ?
It is on Raspberry 2. System dosn’t look overloaded:
red - Processor usage
green - memory
blue - openhab process (in fact Java), it shows more than 100% probably because it scale up to one core
Those pics are during GUI usage, so it looks gui occupied some resources, but not 100% The rest it is working quite well, no LAG. I have also other light www server which provide me other temp charts and it work great.
Open your browser’s developer console, and look at the Log and Network tabs to see if you can determine if there are any Javascript errors, or if the HTTP request to retrieve the chart is really taking all that time.
Do you mean habmin ? If so there is nothing there. I have checked Openhab’s log and there is no problem.
Maybe it is because of persistence data … I have about 50 items. I have restart it and from hardware overload it looks ok.
I am out of ideas
I mean your web browser, as its built-in developer interface can report when the request for the chart is made and when the chart image is returned. I doubt that HABmin is involved.
There is nothing suspicion there. It is simply waiting for data to being delivered. Of course there is no issues on 1gig LAN the rest of gui works fine. Problem is openhab do not deliver chart immediately (within few seconds), sometimes it is ca 30 seconds.
For one of my charts, it takes 278ms waiting for a reply to the request for the chart, and 379ms to download the chart image, so it takes less than one second to request and receive the chart (over wifi, served from a Raspberry Pi 2). So the fact that it takes your setup several seconds, up to 30 seconds, for the chart image to be delivered, suggests either a performance or configuration issue. I’m afraid that I would need more information in order to be able to offer more assistance.
The request you documented is the long-polling request from the client, not the request for the chart image. That request can block for several seconds.
Do you see requests of that sort in the Network tab of your Developer Tools window?
There is a bug in 1.8.1 and previous, fixed in the upcoming 1.8.2, where chart refresh is broken. You might want to follow the instructions there to see if this issue is resolved.
I don’t see refresh of this chart, so I can’t say if it is problem too. for sure problem is first first request. Do you think problem with refresh can affect requests in general ?
Not sure. The problem with the &random=1 is that an old chart could be cached in the browser, since 1 isn’t very random. The change in 1.8.2 makes sure that every chart requested by the Classic UI is fresh, both the initial chart returned and all subsequent charts.
Have you tried the above URL directly, and also by making the random value unique? Does it still take many seconds for the chart image to appear?
Yes I have tried directly to get this image/chart. Same problem, browser is waiting quite long for date.
I am just thinking if it is not due to 2 DBs, which I use, for all items I use db40 with strategy everychange and for few items I use rrd4j with everyminute strategy. Problem occurs with charts from both DBs.
I don’t know where the delay is in the code path for delivering your chart. There are multiple possibilities, anything from DNS resolution problems, overloaded persistent stores, extremely slow image creation code, very slow disk I/O, and on and on. It’s possible that RRD4J or DB4O is having some problem, but there are other possibilities as well. I don’t use either of those persistence services, but you should be able to find where it keeps the files by using find or similar tools on your openHAB server system.
That definitely looks like it could be a problem! Unless db4o is very fast at queries across such a massive datastore, that would be a good area to dig into. And if this is being stored on an SD card, it’s likely going to be worn out quickly and stop working altogether. Even if it’s being stored on an external disk, that might be too much to ask of db4o.