ispCP - Board - Support
[HOWTO] ISPCP Omega - performance tuning... - Printable Version

+- ispCP - Board - Support (http://www.isp-control.net/forum)
+-- Forum: ispCP Omega Contributions Area (/forum-40.html)
+--- Forum: Howtos (/forum-41.html)
+--- Thread: [HOWTO] ISPCP Omega - performance tuning... (/thread-10607.html)



[HOWTO] ISPCP Omega - performance tuning... - kotso - 05-04-2010 09:23 PM

Here is how to optimize your server performance.

It's from my experience and I wrote a small article about it.

ISPCP Omega optimization for performance


RE: [HOWTO] ISPCP Omega - performance tuning... - gagi2 - 05-05-2010 12:25 AM

this link is dead as it could be *lol*


RE: [HOWTO] ISPCP Omega - performance tuning... - kotso - 05-05-2010 03:26 PM

no... link is working...


RE: [HOWTO] ISPCP Omega - performance tuning... - gOOvER - 05-05-2010 03:29 PM

Confirmed. Link is working Smile


RE: [HOWTO] ISPCP Omega - performance tuning... - BytesLand - 05-17-2011 10:16 PM

I read a lot of articles concerning the issue of server optimisation and each time I had lots of questions. But this is the first time I have nothing to ask about, everything is perfectly clear. Will try to implement this asap and will imform you about the results.


RE: [HOWTO] ISPCP Omega - performance tuning... - sumfvm - 05-18-2011 05:11 PM

Error 137 (net::ERR_NAME_RESOLUTION_FAILED)


RE: [HOWTO] ISPCP Omega - performance tuning... - tek - 05-20-2011 11:33 AM

Looks like you have some name server issues which is causing the site to be non-reachable.

Nameserver trace for sys.ge:

Looking for who is responsible for root zone and followed l.root-servers.net.
Looking for who is responsible for ge and followed ns2.nic.fr.
Looking for who is responsible for sys.ge and followed ns2.jeje.ge.
Nameservers for sys.ge:

ns1.jeje.ge returned (NORECORDS)
ns2.jeje.ge returned (NORECORDS)


RE: [HOWTO] ISPCP Omega - performance tuning... - Dylan - 05-22-2011 07:27 AM

Google cache: Big Grin

Quote:ISPCP Omega optimization for performance
Posted on May 4, 2010 by admin

ISPCP Omega is becoming very popular among open source hosting management solutions. For ISP Free hosting we tried many solution but finally choose ISPCP Omega.

Here is couple things I did to reduce load and optimize it for performance.

PHP

For security reasons it use fcgi by default for handling php. It’s good choice but on server with many accounts where all sites are accessed but not often and there is no hight load on any of sites fcgi causes many php-cgi processes using lots of memory.

Right now I have around 1500 user account on ISPCP Omega server, many of them are static pages and I’m thinking about putting reverse proxy before apache for delivering static content but still I have apache, but I have at list 100 sites using php and actively used, but not as actively as I would prefer to be.

Here I will explain advantages and disadvantages of FCGI and CGI technology.

CGI forks separate process on every request, and if there are 1000 requests per second on your page, CGI forks processes 1000 times and each process serves ONLY ONE request and that is main problem of CGI. In general, forking process and then terminating delivers much more load then processing task, that CGI does. So we get situation when exceeds effective payload.

In case of FCGI process is not forked for every request, but it is forked once and processes multiple requests in some time period. Then process terminates and if needed system forks new process. From first look it seems to be very good technology and it has non of disadvantages of CGI technology but in some case it generates more load then CGI, and our case is the one there overhead occurres. Lets consider why, I have 1500 sites on server, for each site FCGI forks multiple processes (3-5 by default) so if all sites are accessed we should have around 5000 FCGI processes running that consumes lots of memory. But my problem is that sites are not used often, let’s say 1-2 users every 10 minute, so that I get a process 3-5 processes forked for the first visitor, next 5 minutes I have no user activity on server so my 3 processes are held in memory without any positive payload. After 5 minutes this processes are terminated an just in couple minutes new users comes to site and causes new 5 processes to be forked.

In my case CGI looks to be better solution but I still use FCGI because if one or multiple pages becomes popular I would have lots of CGI forking/terminations. So I decided to tweak FCGI and make it start few processes and hold them for less time.

Before this experiment load on server was around 5 and reaching 10 in some moments.

You should edit /etc/httpd/conf.d/fastcgi_ispcp.conf (it’s for CentOS for Debian and other look file with similar name in httpd config directory)

Here is my FastCgiConfig:

FastCgiConfig -minProcesses 1 \

-maxProcesses 400 \

-maxClassProcesses 5 \

-multiThreshold 80 \

-killInterval 60 \

-startDelay 5 \

-idle-timeout 120

# -singleThreshold 100 \

# -autoUpdate \

# -pass-header HTTP_AUTHORIZATION

Before modification I had around 800 processes running and after tweak number reduced to 250-300, so I got rid of extra 500 php-cgi processes consuming memory and cpu.

BACKUP

For backups I use BACULA, so I does not need backups that ISPCP Omega creates automatically every night (because of backup process load at night was around 20-30 on server for couple hours).

To disable user site backups go to /etc/ispcp/ispcp.conf and change

BACKUP_DOMAINS = yes

to

BACKUP_DOMAINS = no

and then deleted all backups created by ISPCP Omega with following command:

find /var/www/virtual/ -name *-backup-2010.04.30*.tar.bz2 -exec rm -rf {} \;

last date I make backups was 2010.04.30 so I used that date for finding files.

With this amount of backups was decreased twice.

AWSTAT

Do you really need statistics? Does your users use statistics? or they even don’t know that you have statistics for them. For my case no, my users does not use statistics, so I don’t need it, If you say same go to: /etc/ispcp/ispcp.conf and change

AWSTATS_ACTIVE = yes

to

AWSTATS_ACTIVE = no

so now I have less tasks to do.

SUMMERY:

Server load was 5-10 daytime and 30-40 when creating backups, now load is 1-2 and reaches 5 at 12AM when ISPCP Omega does some daily calculations.



RE: [HOWTO] ISPCP Omega - performance tuning... - clausgruber - 07-11-2011 03:38 AM

Server optimization is one of the crucial issues for smooth operations. thanks for comrehensive information about ISPCP Omega - performance tuning, planning to implement it i nthe nearest time.

Regards.