lighty + usereigene fcgi_prozesse = Performancegarantie?

[mccab99]

Hallo,

Ich habe fünf Instanzen einer gefräßigen Webapplikation (Ressourcen) auf einem Server. Ich möchte allen Benutzern die gleiche Performance garantieren. Jeder User verfügt über eigene fcgi-Prozesse (PHP).

Ich kann über das jeweilige spawning-Verhalten (lässt sich bei lighty ja gut anpassen), jedem User eine maximale Anzahl derartiger Prozesse bereitstellen, wobei die Anzahl von dem zur Verfügung stehendem RAM abhängt.

Die Benutzer müssen jeweils mit 30 Clients simultan arbeiten können. Die notwendige Datenbank läuft auf einer Extramaschine.

Ist das eine eher blöde Idee oder könnte das klappen? Das System dürfte sich bei maximaler Auslastung aller PHP-Threads eines Users ja - so der Gedanke - nur für den betreffenden User verlangsamen. Alle anderen müssten ja flott arbeiten können.

Gruß,

Maik

[aubergine]

Das System dürfte sich bei maximaler Auslastung aller PHP-Threads eines Users ja - so der Gedanke - nur für den betreffenden User verlangsamen.

Also wenn ich jetzt nicht komplett daneben liege könnte ein User durch die 5 geöffneten PHP Instanzen - 5 CPU Cores zu 100% auslasten. Und das bekommen die anderen User je nach Maschine schon mit.

[Joe User]

Ich habe fünf Instanzen einer gefräßigen Webapplikation (Ressourcen) auf einem Server. Ich möchte allen Benutzern die gleiche Performance garantieren. Jeder User verfügt über eigene fcgi-Prozesse (PHP).

Um das zu erreichen solltest du den Usern eigene Gruppen spendieren und einen Kernel mit aktivem/konfiguriertem group-Schedular einsetzen. Und selbst dann kannst Du es nicht garantieren...

Ist das eine eher blöde Idee oder könnte das klappen?

Garantien sind immer blöde Ideen.

Das System dürfte sich bei maximaler Auslastung aller PHP-Threads eines Users ja - so der Gedanke - nur für den betreffenden User verlangsamen. Alle anderen müssten ja flott arbeiten können.

Nein, es wird immer das Gesamtsystem belastet.

[mccab99]

Ok - es fehlten ein paar Infos:

Hauptproblem bei der Applikation ist RAM. Das läuft sehr schnell voll und dann wird es noch schneller kriminell - ist ja irgendwie auch immer so. Der Ramverbrauch steigt mit der Anzahl der Clients, die mit der Applikation arbeiten. Ich kann aber kaum verhindern, dass ein User mit mehr als 30 Clients simultan zugreift, also war der Gedanke, dass es dann eine Art "Selbststrafmechanismus" gibt und die Antwortzeit nur für diesen einen User dann steigt. Das wäre der Idealfall und auf der anderen Seite steht der Swaptod.

75% kommt schon jetzt eh aus irgendwelches Caches - Squid stellt sich z.B. schon erstaunlich tapfer vor das Backend.

Mir ist klar, dass ich mit einer PHP-Instanz den Prozessor zu 100% auslasten kann. Gerade der dümpelt aber auch bei Last (150-200 Clients) mit 20-25% vor sich hin - wenn das je geschehen sollte, dann würde ich schon auf sehr hohem Niveau jammern.

Gruß,

Maik

[Joe User]

Wie sieht denn Dein aktuelles Setup für Lighty aus? Warum benötigt die Applikation soviel Speicher (Wieviel überhaupt?)? Da lässt sich mit Sicherheit noch einiges optimieren...

[mccab99]

Hallo,

Ich fahre im Wesentlichen das mitgelieferte Standardsetup (debian). Lediglich für die einzelnen vhosts nutze ich zusätzlich mod_evhost. Das sieht dann so aus:

Code: Select all

$HTTP["host"] =~ ".somedomain.tld" {


	$HTTP["host"] =~ ".somedomain.tld" { 
		evhost.path-pattern = "/path/to/%3_html/"
	}

	$HTTP["host"] =~ "^(webdir.)" { 
		evhost.path-pattern = "/path/to//%3_data/1/www/"
    		dir-listing.activate ="enable"
		url.access-deny = ( ".php", ".php4", "php5", ".html", ".htm", ".gif", ".jpg", ".png", ".pdf", ".mp3", ".wav", ".mpg", ".ogg", ".mov", ".doc", ".zip", ".tgz", ".tar.gz" )		
	}

Hier die php-cgi-Modulkonfiguration:

Code: Select all

## Start an FastCGI server for php4 (needs the php4-cgi package)
fastcgi.server    = ( ".php" => 
	((
		"bin-path" => "/usr/bin/php5-cgi",
		"socket" => "/tmp/php.socket",
		"max-procs" => 2,
		"idle-timeout" => 20,
		"bin-environment" => ( 
			"PHP_FCGI_CHILDREN" => "4",
			"PHP_FCGI_MAX_REQUESTS" => "10000"
		),
#		"bin-copy-environment" => (
#			"PATH", "SHELL", "USER"
#		),
		"broken-scriptfilename" => "enable"
	))
)

An der php.ini sind folgende Parameter verändert:

max_execution_time = 300 ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
memory_limit = 1024M
post_max_size = 128M
upload_max_filesize = 128M

extension="eaccelerator.so"
eaccelerator.shm_size="64"
eaccelerator.cache_dir="/some/path"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"
eaccelerator.allowed_admin_path = "/path/to/secured/eaccelerator"

Die hohen Werte für memory_limit und Co. sind leider notwendig, da im CRMS hin und wieder 5000er-Datensätze hochgeprügelt werden.

Als PHP-Cache kommt also eaccelerator (selbstcompiliert) mit einer Cachegröße von 64MB zum Einsatz - die Größe habe ich "empirisch" durch dreijähriges Logging ermittelt, ebenso die geeignetsten Parameter für MySQL.

Code: Select all

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket		= /var/run/mysqld/mysqld.sock
nice		= 0

[mysqld]
#
# * Basic Settings
#
user		= mysql
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
language	= /usr/share/mysql/english
skip-external-locking
skip-networking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address		= 127.0.0.1
#
# * Fine Tuning
#
key_buffer		= 128M
sort_buffer		= 8M
max_allowed_packet	= 16M
thread_stack		= 128K
thread_cache_size	= 8
#max_connections        = 100

# Fine tuning tuning_primer.sh suggestions

table_cache             = 120000
open_files_limit	= 360000
#thread_concurrency     = 10
tmp_table_size 		= 1024M
max_heap_table_size	= 1024M
join_buffer_size	= 1024K 

# * Query Cache Configuration
#
query_cache_limit       = 2M
query_cache_size        = 128M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log		= /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration
log_slow_queries	= /var/log/mysql/mysql-slow.log
long_query_time = 5
log-queries-not-using-indexes

#
# The following can be used as easy to replay backup logs or for replication.
#server-id		= 1
log_bin			= /var/log/mysql/mysql-bin.log
# WARNING: Using expire_logs_days without bin_log crashes the server! See README.Debian!
expire_logs_days	= 10
max_binlog_size         = 100M
#binlog_do_db		= include_database_name
#binlog_ignore_db	= include_database_name
#
# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
skip-bdb
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# You might want to disable InnoDB to shrink the mysqld process by circa 100MB.
# skip-innodb
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem

[mysqldump]
quick
quote-names
max_allowed_packet	= 16M

[mysql]
#no-auto-rehash	# faster start of mysql but no tab completition

[isamchk]
key_buffer		= 8M

#
# * NDB Cluster
#
# See /usr/share/doc/mysql-server-*/README.Debian for more information.
#
# The following configuration is read by the NDB Data Nodes (ndbd processes)
# not from the NDB Management Nodes (ndb_mgmd processes).
#
# [MYSQL_CLUSTER]
# ndb-connectstring=127.0.0.1


#
# * IMPORTANT: Additional settings that can override those from this file!
#
!includedir /etc/mysql/conf.d/

innoDB wird für das ansonsten schwach ausgelastete CRMS (vtiger) benötigt.

Alles befindet sich hinter einem Reverse Proxy (Squid), dessen Cache zu ca. 90% gefüllt ist und der ca 75-80% des Gesamtcontents ausliefert.

Einen aktiven Client kann man grob mit ca. 30MB RAM-Bedarf veranschlagen. Die Applikation selbst ist ein großes OpenSource-Projekt (Moodle - http://www.moodle.org), eine Anpassung in derart substantiellen Dingen erscheint mir als fast reiner Linuxadmin und mittelmäßig PHP-Begabter nicht so einfach möglich zu sein.

Ich möchte im Prinzip verhindern, dass ein "Kunde" (= Schule) sein System so sehr nutzt, dass die anderen darunter spürbar leiden. Es handelt sich übrigens um ein Non-Profit-E-Learningprojekt für Schulen...

Gruß,

Maik

[freddy36]

Suchst du http://cpulimit.sourceforge.net/ ?

http://and.sourceforge.net/ könnte auch von Interesse sein.

Ich würde dir empfehlen die fcgi Prozesse getrennt vom lighty zu starten dann auch direkt unter dem jeweiligen user, das bringt mehr Sicherheit+einfachere Zuordnung/Limitierung der Prozesse.

[braindead]

Code: Select all

memory_limit = 1024M 

Bist du dir da sicher? Wenn du nicht mit riesen Datensätzen rumspielst (das würde ich lieber über Stored Procedures in der Datenbank direkt machen) würde ich sagen dein PHP Script hat einen Fehler im Design wenn es wirklich 1024 MB braucht.

[mccab99]

Das Ding nennt sich vtiger und wird nicht wirklich oft verwendet.

Tja - er (der User) wollte eben 6500 Datensätze in einer CSV-Datei hochladen und das ging so gar nicht mit 512MB. Ich will meine Ruhe und die Kiste ist frei von FTP-Zugängen und SCP-Zugängen für User jeder Art. Das hat sich bis jetzt bewährt. Die Leute wollen klicken und nicht lernen oder verstehen - ist leider so.

Ich plane, jedem Account separate fcgi-Threads unter seperaten UIDs zuzuweisen - deswegen ja der Thread hier. CPU-Zeit, ist - wie gesagt - relativ vernachlässigbar. Trotzdem schaue ich mir deionen Tipp auf jeden Fall an. AND sieht auf den ersten Blick sehr gut aus - in der Linuxwelt gibt es ja nix, was es nicht gibt...

Ich werde wahrscheinlich jetzt einmal verstärkt über einen Server mit mehr RAM und das Stichwort "RAM persistente DB" nachdenken. Ich vermute, dass das einen großen Teil meiner Sorgen auch lösen kann.

Vielen Dank fürs Mitdenken!

Gruß,

Maik

[braindead]

Code: Select all

Ich werde wahrscheinlich jetzt einmal verstärkt über einen Server mit mehr RAM und das Stichwort "RAM persistente DB" nachdenken. Ich vermute, dass das einen großen Teil meiner Sorgen auch lösen kann.

Viel Spaß bei der Suche, aber so wie sich das anhört brauchst du einiges an RAM. Ich würde mal an den Programmierer des CRMs gehen und ihn fragen was er da treibt. Ich meine 6500 Datensätze hochladen ist zwar nicht gerade der perfekte Einsatzzweck für PHP, aber ein GB RAM sollte dabei auf keine Fall draufgehen. Wenn die Scripte den Speicher wirklich brauchen wirst du wirklich einen Haufen Speicher brauchen.

[mccab99]

Seufz - leider werden die meisten "hippen" Anwendungen eben nicht von Programmiern entwickelt, sondern im schlimmsten Fall von Pädagogen o.ä. (ansonsten wären sie für Pädagogen wohl auch nicht bedienbar...) - ein Stückweit ist es ja auch legitim, bestimmte Probleme mit Hardware zu erschlagen - die kostet eben weniger als wir Menschen.

Leider hat sich - gerade unter den Pädagogen - leider noch oft nicht herumgesprochen, dass Setups dieser Art auf dem freien Markt eben nicht 10 Euro/Monat kosten...

Gruß,

Maik

[hammerwd]

Hi,

ist das Problem noch aktuell?
Ich habe auch eine Zeit lang mit vtiger gearbeitet, ist ein Split aus SugarCRM (welches ich eher empfehlen würde) - aber eine einfache Idee:
Du brauchst nur zum Import der csv so viel RAM, sonst kommen die beiden CRMs mit recht wenig aus (ich habe Sugar auf 80MB limitiert).
Benutz zum Import der CSV Daten eine andere Maschine, z.B. deinen Desktop, die haben doch meist 2 oder mehr GB. Dann stellst du noch die execution time hoch und portierst nachher die MySQL DB.
So funktioniert das bei mir prima mit 12.000 Datensätzen.

Bye, Chris