Monday 04 July 2005 8:30:16 am

Hi Ben,

form your phpinfo() it looks like you're using php4 not as a module. One of the requirements of eZ publish is, that you use php as a module. The CGI-Version just won't work. See:
http://ez.no/ez_publish/info/requirements_for_ez_publish

Actually there is some issues with those variables set by php (found in your phpinfo()):

_SERVER["REQUEST_URI"]	/phpinfo.php
_SERVER["SCRIPT_NAME"]	/phpinfo.php
_SERVER["PHP_SELF"]	/phpinfo.php

This simply is false. It has to be:

_SERVER["REQUEST_URI"]	/67.15.60.59/protech-golf.com/phpinfo.php
_SERVER["SCRIPT_NAME"]	/67.15.60.59/protech-golf.com/phpinfo.php
_SERVER["PHP_SELF"]	/67.15.60.59/protech-golf.com/phpinfo.php

Seems like something is wrong with your configuration - either in apache or in php. Or this is beacuse you use php4 not as a module in apache. At least it could be something your provider had done to php or apache, too. Tell him that especially those vars are set wrong by php and you don't have a clue how to fix that.

Daniel Beyer
_________________________________
YMC AG
Kreuzlingen, Switzerland
web: www.ymc.ch
____________________________________

Monday 04 July 2005 11:25:52 am

Hi,

if Björn says eZ publish works with php4_cgi than you can trust him. The problem lays in the wrong variables in which some part of the path is missing. I suggest you talk to your provider, maybe he knows whats wrong with it. But hacking eZ publish to solve this issue isn't really a good idea...

Daniel Beyer
_________________________________
YMC AG
Kreuzlingen, Switzerland
web: www.ymc.ch
____________________________________

Monday 04 July 2005 8:04:24 pm

Good morning Ben,

if I get your provider right the address "http://67.15.60.59/67.15.60.59/360sports.co.nz/" is only a temporary one. I think this address is created by using some weird rewrite-rules, that apache or php can't understand.

The problem will solve itself if you connect a domain to 67.15.60.59. Actually the domain 360sports.co.nz is connected on server 210.55.4.14 and not on 67.15.60.59..

I told my notebook that it should use 67.15.60.59 for 360sports.co.nz and that solved your problem.

What you have to do is connecting the domain to server 67.15.60.59. This is done via DNS-entries to which you probably have no access. Talk to your provider(s) to change that for you.

But -as me- you can force your computer to think 360sports.co.nz is connected on 67.15.60.59.

To do that you can add this line to your hosts-file (in most Linux-Distribution located at /etc/hosts):

67.15.60.59    360sports.co.nz

After that clean your dns-cache or reboot your computer.

If you're using Windows you can do this,too. The hosts-file in Windows is located at \WINDOWS\system32\drivers\etc\hosts. The layout of this file is almost the same as in linux. And the same entry should do the job:

67.15.60.59    360sports.co.nz

After that you need to restart your computer. This is the only way I know to get windows to clean its dns-cache.

If you now access http://360sports.co.nz/index.php you should see the setup-page with all its nice images.

Note: Forcing your computer to use an other IP for a domain might not work. A reason for this is probably a proxy between your computer and the remote server.

Attention:
You might discover that 8MB script-limit in php will result in a Fatal Error in eZ publish. But this is an other issue. I suggest you ask your provider for some more memory...

Daniel Beyer
_________________________________
YMC AG
Kreuzlingen, Switzerland
web: www.ymc.ch
____________________________________

Thursday 07 July 2005 2:10:31 pm

Hello all,

after I was gettign Ez up and running after 1 week hard work,I received an email from my webhost admin:
"
I was watching our server load and whenever webbellis.co.nz is invoked it attempts to use 100% of the available CPU, if it was on a dedicated server that would be fine but on a shared server that means other sites are affected when it starts using 90%+ of the available CPU for a single apache instance.

Unfortunatly this means we cannot host this script and it must be removed immediatly. Regrettably this is not negotiable.

Here is some evidence:

22796 apache 23 0 42716 41M 7860 R 88.9 4.1 0:22 0 httpd
(The 88.9 is the % CPU usage from process 22796)

And here is the site responsible for the 22796 PID:
11-0 22796 0/42/42 W 12.81 22 0 0.0 0.42 0.42 219.89.194.16 webbellis.co.nz GET /index.php/plain_admin/content/view/full/43 HTTP/1.1

I'm stucked - has some on an idea what to do ? I mean this website is not the website of the BBC with 1.5 mio hit per day or so ?

I don't no what to do any more :-()

Ben

pixeltransfer design studio
Auckland
New Zealand
Aotearoa

pixeltransfer (at) yahoo.de

Thursday 07 July 2005 10:54:29 pm

Hi Daniel,

many thanks for your suggestions - I forwarded your comments to my web admin and we will see what he can do. He gave me the spec of the server as :
The server you are on is a 2.4Ghz Pentium IV with 1GB ram and is located in the US.

is this is not fast enough ?

Cheers

Ben

pixeltransfer design studio
Auckland
New Zealand
Aotearoa

pixeltransfer (at) yahoo.de

Monday 11 July 2005 12:20:56 am

Sorry Ben,

there is nothing more you can do. Your eZ publish is loading quite fast. As you can see in the debug the server need about 1 second to generate the html-view. This shouldn't be a problem for you provider, as you generate high cpu load only for a short moment. Even in a shared environment this shouldn't be a problem. The only thing to reduce the CPU-Load would be a multi-processor system.

If your provider allows access to php on his servers, than he has to live with the fact, that some scripts will always generate some cpu-load. It his his job to guarantee, that his customers have a stable an fast environment. If a system gets slow he has to make sure, that it keeps usable for all of his customers - either by limiting ressource (eg. limiting the total runtime of php) or by buying better or more hardware.

A friend of mine had a similar problem with his provider. He had a self-scripted cms running in a shared environment. And his provider started to make problems, when his site became pretty popular with several thousands hits a day. But in fact the provider couldn't do anything about it, as my friend used his account just in the way he bought it from him. The end of that story was, that the provider made an offer for an own server for his account to a pretty low price, just to get him off of the shared environment.

One thing may left for you to reduce the cpu load: You could make use of the static cache. But this needs some server-side configuration. And it will take very high cpu-load each time the static cache is generated. But the load the page itself generates would be reduced to a minimum, as php won't be used any longer to display pages from the static cache (the static cache consists of simple html-pages).

Daniel Beyer
_________________________________
YMC AG
Kreuzlingen, Switzerland
web: www.ymc.ch
____________________________________