[vz-users] Login/Absicherung von VZ Installationen
Sirko
mail_ist at nurfuerspam.de
Wed Jan 4 11:51:56 CET 2017
Ergänzung:
ich hab mir die "vielen" SQLs mal genauer angesehen, die sind offenbar
alle von den verschiedenen Tests, d.h. sie sind nur von dem
Benchmark-Request, nicht von anderen Aufrufen an die middleware.
Jeder Request scheint immer einen solchen Block zu verursachen:
{
"sql": "SELECT MAX(timestamp) FROM data WHERE channel_id=1 AND timestamp < (SELECT MAX(timestamp) FROM data WHERE channel_id=1 AND timestamp<1287541654974)",
"execTime": 0.0016069412231445
},
{
"sql": "SELECT MIN(timestamp) FROM data WHERE channel_id=1 AND timestamp>1288488900567",
"execTime": 0.00099301338195801
},
{
"sql": "SELECT aggregate.type, COUNT(aggregate.id) AS count FROM aggregate INNER JOIN entities ON aggregate.channel_id = entities.id WHERE uuid = 'a301d8d0-903b-1234-94bb-d943d061b6a8' GROUP BY type HAVING count > 0 ORDER BY type DESC",
"execTime": 0.00036096572875977
},
{
"sql": "SELECT UNIX_TIMESTAMP(FROM_UNIXTIME(MIN(timestamp) \/ 1000, \"%Y-%m-%d\")) * 1000 FROM aggregate WHERE channel_id=1 AND type=3 AND timestamp >= UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(1287541531460 \/ 1000, \"%Y-%m-%d\"), INTERVAL 1 day)) * 1000",
"execTime": 0.00032901763916016
},
{
"sql": "SELECT UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) \/ 1000, \"%Y-%m-%d\"), INTERVAL 1 day)) * 1000 FROM aggregate WHERE channel_id=1 AND type=3 AND timestamp<1288488900567",
"execTime": 0.00030303001403809
},
{
"sql": "SELECT SUM(count) FROM (SELECT COUNT(1) AS count FROM data WHERE channel_id = 1 AND ( timestamp >= 1287541531460 AND timestamp < 1287612000000 OR timestamp >= 1288476000000 AND timestamp <= 1288488900567) UNION SELECT SUM(count) AS count FROM aggregate WHERE channel_id = 1 AND type = 3 AND timestamp >= 1287612000000 AND timestamp < 1288476000000) AS agg",
"execTime": 0.0071568489074707
},
{
"sql": "SELECT MAX(agg.timestamp) AS timestamp, SUM(agg.value) AS value, COUNT(agg.value) AS count FROM (SELECT timestamp, value, @row:=@row+1 AS row FROM data CROSS JOIN (SELECT @row := 19) AS vars WHERE channel_id=1 AND timestamp >= 1287541531460 AND timestamp <= 1288488900567 ORDER BY timestamp ASC) AS agg GROUP BY row DIV 21 ORDER BY timestamp ASC",
"execTime": 0.3626811504364
},
{
"sql": "SELECT 1",
"execTime": 0.0005497932434082
}
Grüße
Sirko
Am 04.01.2017 um 11:32 schrieb Sirko:
>
> Hi,
>
>
> danke, ich hab's zum Laufen gekriegt. Zunächst nur von Kommandozeile
> ohne Webserver-Änderung (bei mir läuft auch lighttpd).
>
> Ich hab aber mal die Benchmark-URL aufgerufen
> (http://wiki.volkszaehler.org/development/benchmark), einmal über die
> middleware und einmal über ppm auf Port 8088:
>
> http://192.168.178.23/middleware.php/data/a301d8d0-903b-1234-94bb-d943d061b6a8.json?from=1287541654974&to=1288488900567&tuples=1000&debug=1
>
> http://192.168.178.23:8088/data/a301d8d0-903b-1234-94bb-d943d061b6a8.json?from=1287541654974&to=1288488900567&tuples=1000&debug=1
>
>
> Beobachtung:
>
> 1. die Ausgaben sind unterschiedlich, bei wiederholten Aufrufen über
> ppm wird die Zeit immer langsamer und es werden SQLs mit ausgegeben.
> Und zwar mit jedem Aufruf immer mehr. Möglicherweise die, die in der
> Zwischenzeit an die middleware gingen?
>
> 2. Wenn ich debug=5 setze und dann wieder zurück, dann ist der debug
> level wert in der Antwort nicht immer der, der in der URL steht (bei
> Aufrufen über ppm). Man hat das Gefühlt, als ob er den alten level
> wert noch irgendwo gecacht hat.
>
>
> Ausgabe middleware:
>
> {
> "version": "0.3",
> "debug": {
> "level": "1",
> "database": "pdo_mysql",
> "time": 0.01193,
> "uptime": 8217586560,
> "load": [
> 0.15,
> 0.13,
> 0.14
> ],
> "commit-hash": "350a18ca50793e2b8a121a5ec4656f9486b36592",
> "php-version": "5.6.24-0+deb8u1",
> "messages": []
> },
> "data": {
> "tuples": [
> ...
>
>
> Ausgabe ppm:
>
> {
> "version": "0.3",
> "debug": {
> "level": "1",
> "database": "pdo_mysql",
> "time": 621.52648,
> "uptime": 8217662030,
> "load": [
> 0.11,
> 0.13,
> 0.13
> ],
> "commit-hash": "350a18ca50793e2b8a121a5ec4656f9486b36592",
> "php-version": "5.6.24-0+deb8u1",
> "messages": [],
> "sql": {
> "totalTime": 2.032665014267,
> "worstTime": 0.36454510688782,
> "queries": [
> {
> "sql": "SELECT MAX(timestamp) FROM data WHERE channel_id=1 AND timestamp < (SELECT MAX(timestamp) FROM data WHERE channel_id=1 AND timestamp<1287541654974)",
> "execTime": 0.0016129016876221
> },
> und noch hunderte Zeilen sql statements vor den tuples
> Aber, nach einem Neustart des ppm ist nur ein SQL drin (zur
> Erinnerung, die selbe URL über die middleware hatnie SQLs drin in der
> Ausgabe):
>
> {
> "version": "0.3",
> "debug": {
> "level": "1",
> "database": "pdo_mysql",
> "time": 0.68394,
> "uptime": 8217756610,
> "load": [
> 0.04,
> 0.11,
> 0.13
> ],
> "commit-hash": "350a18ca50793e2b8a121a5ec4656f9486b36592",
> "php-version": "5.6.24-0+deb8u1",
> "messages": [],
> "sql": {
> "totalTime": 0.0038230419158936,
> "worstTime": 0.0038230419158936,
> "queries": [
> {
> "sql": "SELECT e0_.id AS id_0, e0_.uuid AS uuid_1, e0_.type AS type_2, p1_.id AS id_3, p1_.pkey AS pkey_4, p1_.value AS value_5, e0_.class AS class_6, p1_.entity_id AS entity_id_7 FROM entities e0_ LEFT JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid = 'a301d8d0-903b-1234-94bb-d943d061b6a8') AND e0_.class IN ('channel', 'aggregator') ORDER BY p1_.pkey ASC",
> "execTime": 0.0038230419158936
> }
> ]
> }
> },
> "data": {
> "tuples": [
>
> mfg
> Sirko
>
> Am 04.01.2017 um 10:41 schrieb Andreas Goetz:
>> Gut, dann wissen wir jetzt über welche Funktion Andre gestolpert ist.
>> Also in der php.ini die disable_functions auskommentieren!
>>
>> Viele Grüße,
>> Andreas
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20170104/46d1481e/attachment.html>
More information about the volkszaehler-users
mailing list