[vz-users] Login/Absicherung von VZ Installationen
Andreas Goetz
cpuidle at gmail.com
Wed Jan 4 12:56:41 CET 2017
Hi Sirko,
danke für den Tipp. Tatsächlich ist die ppm Geschichte Tricky weil eben
globale Variablen bestehen bleiben und nicht automatisch wieder gelöscht
werden. Ich dachte Debuging hätte ich abgefangen:
// initialize debugging
if (($debugLevel = $request->query->get('debug')) || $debugLevel =
Util\Configuration::read('debug')) {
if ($debugLevel > 0 && !Util\Debug::isActivated()) {
new Util\Debug($debugLevel, $this->em);
}
}
else {
// make sure static debug instance is removed
Util\Debug::deactivate();
}
Dein Test sagt also Anderes- das lässt sich aber gut analysieren. Die
schlechter werdene Performance dürfte Swapping sein das einsetzt wenn der
Raspi immer größere Loggings im Speicher mit rumschleppt. Du könntest in
etc/ppm.json auch max-requests z.B. = 20 setzen um zu schauen ob das
Verhalten damit besser wird.
Viele Grüße,
Andreas
2017-01-04 11:51 GMT+01:00 Sirko <mail_ist at nurfuerspam.de>:
> 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/f7e4318b/attachment-0001.html>
More information about the volkszaehler-users
mailing list