[vz-users] Login/Absicherung von VZ Installationen

[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/7dbafe2a/attachment-0001.html>