New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[mysql] use compression protocol #6484

Merged
merged 1 commit into from Mar 1, 2015

Conversation

Projects
None yet
6 participants
@mkortstiege
Member

mkortstiege commented Feb 18, 2015

This enables the mysql compression protocol. The performance benefit is going to be largely dependent on the size of the result sets.

@popcornmix

This comment has been minimized.

Member

popcornmix commented Feb 18, 2015

Any benchmark numbers? Espicially with a slow client or server.
A quick google showed someone warning this option is harmful due to high cpu:
http://karlssonondatabases.blogspot.co.uk/2012/08/mysql-cluster-performance-up-again-or.html

@mkortstiege

This comment has been minimized.

Member

mkortstiege commented Feb 18, 2015

No real benchmarks yet. Entering the movies node (select * from movie_view) was ~50% faster over a really slow internet connection.

Before:

DEBUG: RunQuery took 1088 ms for 359 items query: select * from movie_view

After:

EBUG: RunQuery took 465 ms for 359 items query: select * from movie_view

Did not notice any high cpu issues while testing on regular hardware.

@MilhouseVH is testing this right now as well.

@MilhouseVH

This comment has been minimized.

Contributor

MilhouseVH commented Feb 18, 2015

These are my results on three clients - a Pi1, Pi2, and Ubuntu x86.

In all cases the database is MySQL 5.5 on an HP N36L (8GB RAM, FreeNAS/FreeBSD), with all clients and server wired into a GigE network.

"BEFORE" is without compression, "AFTER" is with compression.

Pi1 (1000MHz ARM, OpenELEC build #217):
Movies (Titles):

BFFORE: 19:35:15 80369.109375 T:1968140288   DEBUG: RunQuery took 123 ms for 694 items query: select * from movie_view
BEFORE: 19:35:40 80394.382812 T:1968140288   DEBUG: RunQuery took 149 ms for 694 items query: select * from movie_view
BEFORE: 19:36:00 80414.015625 T:1968140288   DEBUG: RunQuery took 167 ms for 694 items query: select * from movie_view

AFTER : 19:43:11   286.509735 T:1968152576   DEBUG: RunQuery took 228 ms for 694 items query: select * from movie_view
AFTER : 19:43:29   304.470673 T:1968152576   DEBUG: RunQuery took 336 ms for 694 items query: select * from movie_view
AFTER : <file cached>

Movie Sets:

BEFORE: 19:30:42 80096.328125 T:1968033792   DEBUG: RunQuery took 89 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet
BEFORE: 19:31:26 80140.125000 T:1968033792   DEBUG: RunQuery took 112 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet
BEFORE: 19:31:48 80161.882812 T:1968033792   DEBUG: RunQuery took 93 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet

AFTER : 19:44:17   351.574890 T:1968152576   DEBUG: RunQuery took 113 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet
AFTER : 19:44:35   370.232147 T:1968152576   DEBUG: RunQuery took 146 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet
AFTER : 19:44:49   383.807373 T:1968152576   DEBUG: RunQuery took 174 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet

TV Shows:

BEFORE: 19:32:41 80215.062500 T:1968033792   DEBUG: RunQuery took 96 ms for 67 items query: SELECT * FROM tvshow_view
BEFORE: 19:32:52 80226.382812 T:1968033792   DEBUG: RunQuery took 72 ms for 67 items query: SELECT * FROM tvshow_view
BEFORE: 19:33:07 80240.671875 T:1968033792   DEBUG: RunQuery took 56 ms for 67 items query: SELECT * FROM tvshow_view

AFTER : 19:45:05   400.033478 T:1968152576   DEBUG: RunQuery took 120 ms for 67 items query: SELECT * FROM tvshow_view
AFTER : 19:45:25   420.437653 T:1968152576   DEBUG: RunQuery took 178 ms for 67 items query: SELECT * FROM tvshow_view
AFTER : 19:45:43   437.731140 T:1968152576   DEBUG: RunQuery took 157 ms for 67 items query: SELECT * FROM tvshow_view

In the case of the Pi1, it would more frequently use a local file cache when compression is enabled - Kodi will use a file cache if the query takes longer than a minimum amount of time, I believe. I tried to capture the query time several times, but Kodi would all too frequently switch to a file cache on the Pi1 with compression enabled.

Pi2 (1000Mhz ARM, OpenELEC build #217):
Movies (Titles):

BFFORE: 18:54:56 77918.023438 T:1969049600   DEBUG: RunQuery took 104 ms for 694 items query: select * from movie_view
BEFORE: 19:03:02 78403.406250 T:1969049600   DEBUG: RunQuery took 103 ms for 694 items query: select * from movie_view
BEFORE: 19:03:10 78411.601562 T:1969049600   DEBUG: RunQuery took 103 ms for 694 items query: select * from movie_view

AFTER : 19:15:30   489.017029 T:1969033216   DEBUG: RunQuery took 170 ms for 694 items query: select * from movie_view
AFTER : 19:16:33   551.510742 T:1969033216   DEBUG: RunQuery took 283 ms for 694 items query: select * from movie_view
AFTER : 19:16:56   574.070129 T:1969033216   DEBUG: RunQuery took 173 ms for 694 items query: select * from movie_view

Movie Sets:

BEFORE: 19:03:21 78422.609375 T:1969049600   DEBUG: RunQuery took 60 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet
BEFORE: 19:03:36 78437.742188 T:1969049600   DEBUG: RunQuery took 58 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet

AFTER : 19:17:13   591.907715 T:1969033216   DEBUG: RunQuery took 135 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet
AFTER : 19:17:20   598.244263 T:1969033216   DEBUG: RunQuery took 112 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet

TV Shows:

BEFORE: 19:02:24 78365.750000 T:1969049600   DEBUG: RunQuery took 73 ms for 67 items query: SELECT * FROM tvshow_view
BEFORE: 19:02:38 78379.734375 T:1969049600   DEBUG: RunQuery took 71 ms for 67 items query: SELECT * FROM tvshow_view
BEFORE: 19:02:49 78390.679688 T:1969049600   DEBUG: RunQuery took 62 ms for 67 items query: SELECT * FROM tvshow_view

AFTER : 19:18:08   646.145569 T:1969033216   DEBUG: RunQuery took 92 ms for 67 items query: SELECT * FROM tvshow_view
AFTER : 19:18:16   654.265625 T:1969033216   DEBUG: RunQuery took 113 ms for 67 items query: SELECT * FROM tvshow_view
AFTER : 19:18:23   661.145630 T:1969033216   DEBUG: RunQuery took 111 ms for 67 items query: SELECT * FROM tvshow_view

Much less reliance on the file cache while using the Pi2, with or without compression.

x86 (AMD FX-8350 4GHz CPU, Ubuntu 14.10, Kodi master):
Movies (Titles):

BFFORE: 19:56:26 T:140267865766080   DEBUG: RunQuery took 104 ms for 694 items query: select * from movie_view
BEFORE: 19:56:37 T:140267865766080   DEBUG: RunQuery took 13 ms for 694 items query: select * from movie_view
BEFORE: 19:56:45 T:140267865766080   DEBUG: RunQuery took 53 ms for 694 items query: select * from movie_view

AFTER : 20:02:42 T:140089844930752   DEBUG: RunQuery took 123 ms for 694 items query: select * from movie_view
AFTER : 20:02:47 T:140089844930752   DEBUG: RunQuery took 121 ms for 694 items query: select * from movie_view
AFTER : 20:02:52 T:140089844930752   DEBUG: RunQuery took 122 ms for 694 items query: select * from movie_view

Movie Sets:

BEFORE: 19:58:21 T:140267865766080   DEBUG: RunQuery took 23 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet
BEFORE: 19:58:31 T:140267865766080   DEBUG: RunQuery took 10 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet
BEFORE: 19:58:34 T:140267865766080   DEBUG: RunQuery took 46 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet

AFTER : 20:03:45 T:140089844930752   DEBUG: RunQuery took 49 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet
AFTER : 20:03:50 T:140089844930752   DEBUG: RunQuery took 48 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet
AFTER : 20:03:54 T:140089844930752   DEBUG: RunQuery took 66 ms for 269 items query: select * from movie_view  JOIN sets ON movie_view.idSet = sets.idSet ORDER BY sets.idSet

TV Shows:

BEFORE: 19:59:09 T:140267865766080   DEBUG: RunQuery took 2 ms for 67 items query: SELECT * FROM tvshow_view
BEFORE: 19:59:28 T:140267865766080   DEBUG: RunQuery took 3 ms for 67 items query: SELECT * FROM tvshow_view
BEFORE: 19:59:32 T:140267865766080   DEBUG: RunQuery took 3 ms for 67 items query: SELECT * FROM tvshow_view

AFTER : 20:04:30 T:140089844930752   DEBUG: RunQuery took 7 ms for 67 items query: SELECT * FROM tvshow_view
AFTER : 20:04:36 T:140089844930752   DEBUG: RunQuery took 7 ms for 67 items query: SELECT * FROM tvshow_view
AFTER : 20:04:40 T:140089844930752   DEBUG: RunQuery took 13 ms for 67 items query: SELECT * FROM tvshow_view

In every case, the queries are slower when compression is enabled, usually by 50% or more, even on the Ubuntu client. This would suggest the problem (extra overhead) is with the HP N36L server, and not the clients. However the server shows very little load during the queries (2-3% max) but given the short duration of the queries the actual load could be 100% for only 100ms or so. Either way, it appears the AMD Athlon II Neo 1.3GHz CPU isn't too hot on zlib compression.

If the MySQL compression feature is to be supported, I'd definitely suggest an advancedsetting so that it can be enabled as it should be left disabled by default. If my results are typical of low-end server hardware, then compression (in a wired network) may only be of benefit when the MySQL server is reasonably powerful (i3+), which probably rules out a lot of server hardware that is currently used to run MySQL for Kodi (Synology etc.).

However even with a low-end server, compression may still be of some benefit over a WiFi (or internet) connection. Perhaps someone can capture query timings with/without compression over a WiFi connection.

@Paxxi

This comment has been minimized.

Member

Paxxi commented Feb 18, 2015

Did you get any data on transfer sizes or compression ratio? I Don't think the cpu in your server is the bottleneck, rather that the data is so small that it fits in a few packets without waiting for acks so any compression/decompression just adds extra overhead. On further thought even on larger data sizes the round trip time is short enough to not really matter on a home lan.

@MilhouseVH

This comment has been minimized.

Contributor

MilhouseVH commented Feb 18, 2015

No, I don't think that information is available in the Kodi log, and it's probably transparent to the client. Observing network traffic isn't reliable either, as it can include NFS/SMB/etc traffic. I guess sniffing the wire might be one solution.

This is the difference in wire traffic RX/TX when entering Movies (Titles) on the Pi2:

Without compresson:
Time         ARM    Core    H264 Core Temp (Max)  IRQ/s     RX B/s     TX B/s GPUMem Free  %user  %nice   %sys  %idle  %iowt   %irq %s/irq %total   cpu0   cpu1   cpu2   cpu3 Memory Free/Used
======== ======= ======= ======= =============== ====== ========== ========== =========== ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== ================

21:04:08 1000Mhz  500Mhz    0Mhz 49.23C (50.31C)  2,006  1,286,230     95,191 239M ( 79%)  19.49   0.93   3.71  73.08   0.00   0.00   0.46  26.92  50.82  12.77  27.62  16.48 625,260 kB/ 9.5%
21:04:09 1000Mhz  500Mhz    0Mhz 50.84C (50.84C)  3,377  1,053,228    214,292 238M ( 79%)  11.41   0.70   4.43  80.12   0.00   0.00   0.70  19.88  44.10   4.04   8.70  23.61 625,288 kB/ 9.5%
21:04:11 1000Mhz  500Mhz    0Mhz 48.15C (50.84C)  1,407    289,356     63,519 238M ( 79%)   4.02   0.47   1.66  92.57   0.00   0.00   0.00   7.43  13.82   3.40   1.51  10.98 625,296 kB/ 9.5%
21:04:12 1000Mhz  500Mhz    0Mhz 48.69C (50.84C)    630        233        472 238M ( 79%)   1.42   0.71   0.95  97.00   0.00   0.00   0.00   3.00   1.58   2.53   0.63   6.31 625,648 kB/ 9.4%
...
21:04:21 1000Mhz  500Mhz    0Mhz 50.31C (50.84C)  1,978  1,273,964     92,904 246M ( 82%)  17.94   0.47   4.19  73.62   0.00   0.00   0.93  26.38  73.91  10.53  13.33   7.74 624,400 kB/ 9.6%
21:04:22 1000Mhz  500Mhz    0Mhz 50.84C (50.84C)  3,343  1,043,820    211,544 238M ( 79%)  10.50   0.93   4.20  80.00   0.00   0.00   0.93  20.00  41.23  18.84  11.37   8.57 624,040 kB/ 9.7%
21:04:23  999Mhz  500Mhz    0Mhz 49.23C (50.84C)  1,483    316,992     69,049 238M ( 79%)   3.56   0.24   2.13  92.49   0.00   0.00   0.47   7.51  15.58  10.83   3.24   1.35 624,292 kB/ 9.6%
21:04:24 1000Mhz  500Mhz    0Mhz 48.15C (50.84C)    630        167        451 238M ( 79%)   1.42   0.47   0.71  96.84   0.00   0.00   0.00   3.16   3.16   5.06   3.16   1.27 624,328 kB/ 9.6%
21:04:25 1000Mhz  500Mhz    0Mhz 50.31C (50.84C)  1,220    174,102     42,977 238M ( 79%)   5.85   2.58   3.75  86.39   0.00   0.00   0.00  13.61  13.84  27.89   6.35   5.41 624,064 kB/ 9.7%
...
21:04:31 1000Mhz  500Mhz    0Mhz 49.77C (50.84C)  1,937  1,237,659     90,323 246M ( 82%)  17.87   0.46   3.90  74.69   0.00   0.00   0.92  25.31  72.51  15.68   8.35   4.69 623,368 kB/ 9.8%
21:04:32 1000Mhz  500Mhz    0Mhz 51.38C (51.38C)  3,336  1,041,987    210,244 238M ( 79%)  12.43   1.17   4.22  79.76   0.00   0.00   0.94  20.24  46.51   5.22  23.99   4.28 623,728 kB/ 9.7%
21:04:33 1000Mhz  500Mhz    0Mhz 49.77C (51.38C)  1,546    341,506     74,162 238M ( 79%)   3.32   0.71   1.90  92.01   0.00   0.00   0.24   7.99  15.58   4.20  10.84   2.30 623,556 kB/ 9.8%
21:04:34 1000Mhz  500Mhz    0Mhz 48.69C (51.38C)    630         87        474 238M ( 79%)   1.66   0.47   0.95  96.77   0.00   0.00   0.00   3.23   1.34   3.23   6.08   1.34 623,700 kB/ 9.7%
21:04:35  999Mhz  500Mhz    0Mhz 51.38C (51.38C)  1,228    174,876     43,608 238M ( 79%)   7.52   2.58   2.82  85.05   0.00   0.00   0.47  14.95  22.00  28.58   6.97   1.33 623,280 kB/ 9.8%^
With compression:
Time         ARM    Core    H264 Core Temp (Max)  IRQ/s     RX B/s     TX B/s GPUMem Free  %user  %nice   %sys  %idle  %iowt   %irq %s/irq %total   cpu0   cpu1   cpu2   cpu3 Memory Free/Used
======== ======= ======= ======= =============== ====== ========== ========== =========== ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== ====== ================

20:58:55 1000Mhz  500Mhz    0Mhz 46.54C (47.62C)  1,432    423,714     43,497 232M ( 77%)  15.88   0.92   2.99  77.33   0.00   0.00   0.69  22.67  39.24  33.71  10.70   7.02 616,740 kB/10.7%
20:58:56 1000Mhz  500Mhz    0Mhz 49.77C (49.77C)  2,524    292,038    136,264 208M ( 69%)  15.48   1.39   7.16  73.25   0.00   0.00   0.92  26.75  58.41  20.51  14.97  13.12 617,568 kB/10.6%
20:58:58 1000Mhz  500Mhz    0Mhz 49.23C (49.77C)  2,646    282,784    159,993 208M ( 69%)  12.91   0.94   3.75  80.96   0.00   0.00   0.70  19.04  54.94  14.58   4.25   2.37 617,420 kB/10.6%
20:58:59 1000Mhz  500Mhz    0Mhz 47.62C (49.77C)    788      3,910      2,826 208M ( 69%)   1.43   0.48   0.95  96.74   0.00   0.00   0.00   3.26   3.02   6.82   3.02   1.12 617,576 kB/10.6%
...
20:59:13 1000Mhz  500Mhz    0Mhz 47.08C (49.77C)  1,034    368,180     15,246 240M ( 80%)  13.48   0.47   1.42  83.49   0.00   0.00   0.00  16.51   5.40  53.64   3.50   2.56 617,328 kB/10.7%
20:59:14 1000Mhz  500Mhz    0Mhz 49.77C (49.77C)  2,474    288,387    126,167 208M ( 69%)  17.76   1.38   7.84  70.11   0.00   0.00   0.46  29.89  57.56  39.11  19.74   4.05 617,708 kB/10.6%
20:59:16 1000Mhz  500Mhz    0Mhz 49.77C (49.77C)  2,599    275,538    155,900 208M ( 69%)  13.63   0.94   3.52  79.88   0.00   0.00   1.17  20.12  49.25  18.24   6.96   6.02 617,396 kB/10.6%
20:59:17 1000Mhz  500Mhz    0Mhz 48.69C (49.77C)  1,331     84,431     49,221 208M ( 69%)   6.13   0.94   2.12  89.84   0.47   0.00   0.24  10.16  18.88  15.11   0.96   4.74 617,336 kB/10.7%
...
20:59:28 1000Mhz  500Mhz    0Mhz 48.69C (50.84C)    963    276,188     10,824 234M ( 78%)   3.79   0.71   1.66  92.99   0.00   0.00   0.47   7.01  20.50   2.52   3.47   1.57 617,204 kB/10.7%
20:59:29  999Mhz  500Mhz    0Mhz 49.23C (50.84C)  1,806    257,121     75,799 234M ( 78%)  20.26   0.47   3.30  73.75   0.00   0.00   0.94  26.25  73.61  25.54   3.86   1.98 617,036 kB/10.7%
20:59:30 1000Mhz  500Mhz    0Mhz 51.38C (51.38C)  2,626    292,911    150,049 226M ( 75%)  14.04   0.70   4.21  77.69   0.00   0.00   0.94  22.31  55.07  25.12   5.47   3.60 617,044 kB/10.7%
20:59:31 1000Mhz  500Mhz    0Mhz 50.31C (51.38C)  2,067    194,893    111,322 226M ( 75%)   9.72   0.71   2.37  85.54   0.00   0.00   0.24  14.46  36.49  15.64   4.27   0.47 617,292 kB/10.7%

So there is a significant reduction in the RX figures, as much as 75% reduction (TX is also reduced), although I'm not able to say how much of this is SQL related (though given that the only difference between the tests is the addition of compression, perhaps it's entirely SQL data, though not sure why the transfers are multi-second when the queries are completing sub-second).

Benchmarking compression properly probably requires a small test client (C++, same libraries as Kodi) that can be used to compare the benefits of MySQL compression for a variety of typical Kodi queries. This would yield a much greater degree of accuracy/confidence than you will get from analysing the Kodi debug log, which is at best indicative.

I'll include this PR in tonights Pi1/Pi2 OpenELEC test builds, which may allow us to capture more results on different networks and server setups.

@mkortstiege

This comment has been minimized.

Member

mkortstiege commented Feb 19, 2015

Thanks a lot for testing! Let's see if it works out for some and then decide whether or not to add it as advanced setting. I will run some test with a regular setup as well.

@MilhouseVH

This comment has been minimized.

Contributor

MilhouseVH commented Feb 19, 2015

I've asked for feedback in my testing thread - started to get some, but hope to get more.

I suspect we'll probably get a significant win on WiFi and other bandwidth constrained connections, but quite often lose (or just a small win) on wired connections - higher performance servers may still add a few percentage of compression overhead, which may then be eliminated by the subsequent reduced bandwidth. Lower performance servers simply add too much compression overhead for it to be clawed back by reduced bandwidth.

@mkortstiege

This comment has been minimized.

Member

mkortstiege commented Feb 19, 2015

Here are my timings using a Core i7-4770 @ 3.40GHz running Ubuntu 14.10 as client and a Pentium 4 @ 2.40GHz running the database (MySQL 5.5) on a GigE network.

Without compresson:
DEBUG: RunQuery took 295 ms for 500 items query: select * from movie_view
DEBUG: RunQuery took 287 ms for 500 items query: select * from movie_view
DEBUG: RunQuery took 283 ms for 500 items query: select * from movie_view
With compresson:
DEBUG: RunQuery took 231 ms for 500 items query: select * from movie_view
DEBUG: RunQuery took 206 ms for 500 items query: select * from movie_view
DEBUG: RunQuery took 231 ms for 500 items query: select * from movie_view

Apparently the performance gain is pretty low compared to using the same server over the internet. So the real benefit using compression is dependent on network bandwidth, latency between the database and the clients and the the actual client that has to handle the zlib compression.

@mkortstiege mkortstiege added the RFC label Feb 23, 2015

@mkortstiege

This comment has been minimized.

Member

mkortstiege commented Feb 24, 2015

Updated. Using protocol compression is now optional and defaults to false.

@MilhouseVH

This comment has been minimized.

Contributor

MilhouseVH commented Feb 24, 2015

Getting bugger all feedback, I'm afraid. :(

@mkortstiege

This comment has been minimized.

Member

mkortstiege commented Feb 24, 2015

Jep, so i made it optional. Tests showed that users with slow connections to their backends benefit from it. Objections or comments?

@MilhouseVH

This comment has been minimized.

Contributor

MilhouseVH commented Feb 24, 2015

Optional (default: false) is the right choice IMHO. Perhaps in time there will be sufficient metrics/evidence to be able to say that WiFi (and other bandwidth constrained) users should enable this by default.

OT, but looking at your changes it appears the tvdatabase and epgdatabase can also use MySQL, I thought it was only video and music... I wonder if anyone has tested this with MySQL? :)

And this needs a separate PR, but surely it's time to drop the videodb warning?

@mkortstiege

This comment has been minimized.

Member

mkortstiege commented Feb 25, 2015

I have no idea if that is supported but i added it there for the sake of consistency.

IMO it's still kinda experimental and (unfortunately) still way slower than using sqlite but i agree that it makes no sense to have it there for just the videodb. Feel free to remove that warning.

@mkortstiege

This comment has been minimized.

Member

mkortstiege commented Feb 25, 2015

jenkins build this please

@mkortstiege mkortstiege added this to the I******* 15.0-alpha2 milestone Feb 25, 2015

@sopparus

This comment has been minimized.

sopparus commented Feb 25, 2015

I use mysql over vpn, and have 2-3 ms to the mysql server, Both server and client is pretty fast.

Three runquerys from kodi without compression. 469, 439, 429 and 433.
Three with compression, 159, 153, 149

If I use mysql client and do select * from movieview ; I get 0.29 without and 0.09 with compression.

@mkortstiege

This comment has been minimized.

Member

mkortstiege commented Mar 1, 2015

jenkins build and merge

@jenkins4kodi jenkins4kodi merged commit 8a00df3 into xbmc:master Mar 1, 2015

1 check was pending

default Merged build started.
Details

@mkortstiege mkortstiege deleted the mkortstiege:mysql_compress branch Mar 6, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment