[Phpmyadmin-devel] Realtime charting

Thu Jun 2 13:05:48 CEST 2011

On Tue, May 31, 2011 at 11:45 AM, Tyron Madlener <tyronx at gmail.com> wrote:
> On Tue, May 31, 2011 at 10:13 AM, Michal Čihař <michal at cihar.com> wrote:
>> Hi
>>
>> Dne Tue, 31 May 2011 00:12:31 +0200
>> Tyron Madlener <tyronx at gmail.com> napsal(a):
>>
>>> I've added now a first version of my planned realtime charting on the
>>> status page in the 'Query statistics'-Tab (click on "Realtime chart").
>>> You can check it out at http://demo.phpmyadmin.net/gsoc-tyron
>>>
>>> Currently it aggregates the average queries per second by making an
>>> ajax request every 2-2.5 seconds (2 seconds + time for one ajax
>>> request). Since it is using the differential of the status var
>>> 'questions' it takes some seconds to display a line.
>>>
>>> For the chart I'm currently using Highcharts because it allows
>>> realtime data, animates beautifully, is really small (1 file, 77kb
>>> minified) and has a export to png/pdf/jpg plugin (6.4kb minified)
>>> which however uses a highcharts.com server for the conversion.
>>
>> Depending on external service is not something I would like to see.
>
> Thats indeed not very nice. Maybe with some hacking around I could
> build my own svg to png/pdf converter for phpmyadmin. There must be a
> library for that. The code for converting the charts is availabe from
> highcharts.com, but from what I've seen its partially written in java.
> But it cannot be that hard to build our own php-only-solution.
>
>>
>>> Some radical suggestion in this regard: What about removing the
>>> included pChart and instead using a client-side charting library? I
>>> know for some part its bad since a student wrote a whole lot of code
>>> for it just last year, but looking at some requirements for phpmyadmin
>>> (no file storage, limited possibilities for data recording,
>>> panning/zooming, realtime updates) a server-side charting library
>>> offers much less possibilities compared to a client side-one. And if
>>> we'd use highcharts it would save us like 16 files and 750kb (well
>>> most of it is that dejavu font).
>>> I think it would be pretty easy to replace actually. Instead of the
>>> graph, the server-code would just need to send the already generated
>>> chart data hidden in the document and then we add a bit of js code to
>>> display the chart. Some code from chart.lib.php is probably reusable.
>>
>> There has been lot of discussion what to use and we stick with sever
>> side solution because it did allow saving of the images (what might
>> be not that useful for server stats, while is definitely useful when
>> drawing chart from query results) and does not require javascript
>> (though this is less and less important nowadays).
>
> Actually the way how pChart is currently implemented it generates the
> charts in slices, so at the moment you cannot save them.
>
>>
>> However for realtime charts, server side solution will indeed
>> perform worse. And there is also need for some client side graphics
>> library for spatial extensions, so I'd like to see one client side
>> library used for both drawing spatial data and for charting.
>>
>
> I basically agree, since adding more and more libraries creates only
> more feature creep and inconsistency.
> The reason I'm not very fond of using the suggested svg drawing
> library (jQuery SVG) is that it has not been specifically built for
> charting. The plotting examples on the website look rather clumsy and
> I couldn't find any support for real-time data.
>
> So, if I'm going to build real-time charting for pma using jQuery SVG,
> I will have to write and maintain some sort of
> real-time-charting-plugin that likely will consume between a few days
> and a week of time.
>
> It seems more "future-proof" for me to invest that time in replacing
> pChart with a client-lib like highcharts and thus still having only 2
> graphing libs in pma.
>
>> Whether it will be possible to replace pChart or not later, that's IMHO
>> different question (mostly depending on usable way of exporting charts
>> out of client side solution).
>
> pChart is currently used only in 3 different place, no?
> - server status page
> - query profiling pie
> - query result charting
>
> When I was looking at the code, it seemed fairly easy to replace it.
>
> I will do some research on the code of highcharts export, jquery svg
> and pchart the next days so I can make a more exact estimation of the
> time it would require to add the missing requirements or replace with
> another lib in the case of pchart.
>

After some testing and research I found out that:
- The pma_pchart classes, by default, slice the picture into 20
pieces, and that for every browser. It was implemented that way
because IE8 limits data URIs to 32kb.
- Images generated by pChart are around 20-40 kb in size.
- IE7 does not support data URIs (=no pcharts for IE7 at all)
- Whereas Highcharts works in IE7 and IE8 (according to the website
also in IE6 but I didn't test that)

So from what I can see:
- Highcharts works in IE7; pChart does not
- Exporting images requires a server side export feature for
Highcharts (which is going to be developed anyway for OpenGIS);
Exporting in pChart would require either non-sliced images and thus
breaking IE8 support or alternatively a server side export feature as
well.
- Highcharts is fast, interactive and animated, pChart is not (except
for tooltips)
- Highcharts allows realtime charts, pChart does not
- Highcharts requires ~90kb minified and 2 files, pChart with its
wrapper classes currently requires ~850kb and 18 files
- Highcharts is still being actively developed (last change march
2011), pCharts 1.x is not (last change september 2008)

- If pCharts were to be replaced by Highcharts, it would not require
12 wrapper classes. Rather just 1 that allows for easy extension with
$.extend() and is client side. Highcharts is imo significantly easier
to use than pCharts, mostly because coding in javascript has some
clear advantages over php (OOP-wise). Since charting is used only in 3
places, it should be a matter of a few days to replace it.

- Compared with jQuery SVG: Highcharts is particularly made for
charting, thus giving a great look&feel and is very easy to use as a
developer; jQuery SVG is not, thus looking inappropriate for charting
and will result in less readable and more complicated code (or
requires time-intensive coding of wrapper classes/plugins which can
maybe partly remedy those disadvantages)

Hence my question, why haven't I been ordered to replace pChart with
Highcharts already? ;-)

> As always thanks for all the feedback and more is always welcome :)
>
>>
>> --
>>        Michal Čihař | http://cihar.com | http://blog.cihar.com
>>
>> ------------------------------------------------------------------------------
>> Simplify data backup and recovery for your virtual environment with vRanger.
>> Installation's a snap, and flexible recovery options mean your data is safe,
>> secure and there when you need it. Data protection magic?
>> Nope - It's vRanger. Get your free trial download today
>> http://p.sf.net/sfu/quest-sfdev2dev
>> _______________________________________________
>> Phpmyadmin-devel mailing list
>> Phpmyadmin-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
>>
>>
>