lighttpd forum XCache > another bug

well used the latest SVN of xcache.

http://www.thecenter.at/downloads/Skins/counterstrike/index.php?module=Pagesetter&func=viewpub&tid=3&pid=1605

he makes of www.thecenter.at
the server address
www.thecenter.at/downloads/Skins/counterstrike

which is NOT correct.. thats why all relative links suddenly have wrong 
urls throwing 404. ;)

i know u heard it before. but i didnt had this with apc

xcache seems to be far away from being ready for production usage. ;)

best regards

Simon
PS: swtiching back to APC if you dont mind. ;)

Simon Lange wrote:
> well used the latest SVN of xcache.
> 
> http://www.thecenter.at/downloads/Skins/counterstrike/index.php?module=Pagesetter&func=viewpub&tid=3&pid=1605
> 
> he makes of www.thecenter.at
> the server address
> www.thecenter.at/downloads/Skins/counterstrike
> 
> which is NOT correct.. thats why all relative links suddenly have wrong 
> urls throwing 404. ;)
do u mean the picture urls? but what's the correct url (what should it
be)?
and what php app are u using?

> PS: swtiching back to APC if you dont mind. ;)
no problem :)


guessing possible workarround:
add
auto_globals_jit = Off
in your ini.

moo moo wrote:
> Simon Lange wrote:
>> well used the latest SVN of xcache.
>> 
>> http://www.thecenter.at/downloads/Skins/counterstrike/index.php?module=Pagesetter&func=viewpub&tid=3&pid=1605
>> 
>> he makes of www.thecenter.at
>> the server address
>> www.thecenter.at/downloads/Skins/counterstrike
>> 
>> which is NOT correct.. thats why all relative links suddenly have wrong 
>> urls throwing 404. ;)
> do u mean the picture urls? but what's the correct url (what should it
> be)?
> and what php app are u using?
oh i thought i stated it clear enough.
xcache causes a WRONG server address!
as written above. instead of (correct) www.thecenter.at which is the
server address
it takes an URI as server address

it had to be:
http://www.thecenter.at/index.php?module=Pagesetter&func=viewpub&tid=3&pid=1605

but xcache produced:
http://www.thecenter.at/downloads/Skins/counterstrike/index.php?module=Pagesetter&func=viewpub&tid=3&pid=1605

what do you mean with php app?! you talk about the php VERSION (5.1.4) 
or do you
talk about the CMS (postnuke .762)?

>> PS: swtiching back to APC if you dont mind. ;)
> no problem :)
yep, but id love to have a more optimized and with fastcgi working
solution. ;)

> guessing possible workarround:
> add
> auto_globals_jit = Off
> in your ini.
its already off. ;)

regards

Simon

> oh i thought i stated it clear enough.
> xcache causes a WRONG server address!
> as written above. instead of (correct) www.thecenter.at which is the
> server address
> it takes an URI as server address
> 
> it had to be:
> http://www.thecenter.at/index.php?module=Pagesetter&func=viewpub&tid=3&pid=1605
> 
> but xcache produced:
> http://www.thecenter.at/downloads/Skins/counterstrike/index.php?module=Pagesetter&func=viewpub&tid=3&pid=1605
> 
ok, so you wanted to say "www.thecenter.at is redirected to (or produce 
links as) http://www.thecenter.at/downloads/Skins/counterstrike" instead 
of "he makes of www.thecenter.at the server address 
www.thecenter.at/downloads/Skins/counterstrike"

> what do you mean with php app?! you talk about the php VERSION (5.1.4) 
> or do you
> talk about the CMS (postnuke .762)?
yeah. i'd like to see if someone can trace down the problem, and make a 
short reproducable script.

> yep, but id love to have a more optimized and with fastcgi working
> solution. ;)
apc should work with fastcgi, doesn't it?

moo moo wrote:
>> oh i thought i stated it clear enough.
>> xcache causes a WRONG server address!
>> as written above. instead of (correct) www.thecenter.at which is the
>> server address
>> it takes an URI as server address
>> 
>> it had to be:
>> http://www.thecenter.at/index.php?module=Pagesetter&func=viewpub&tid=3&pid=1605
>> 
>> but xcache produced:
>> http://www.thecenter.at/downloads/Skins/counterstrike/index.php?module=Pagesetter&func=viewpub&tid=3&pid=1605
>> 
> ok, so you wanted to say "www.thecenter.at is redirected to (or produce 
> links as) http://www.thecenter.at/downloads/Skins/counterstrike" instead 
> of "he makes of www.thecenter.at the server address 
> www.thecenter.at/downloads/Skins/counterstrike"
procuding not redirecting... but i have meanwhile found what happened.
it seems xcache has problems with pnRender which is used by several cms 
system e.g. postnuke.
when using xcache the first time its a MUST to clear pnRender's cache 
AND (although it wasnt even enabled before) clearing xcache's cahce.
since 4 hours it works without noticeble problems.
but i keep an eye on it, snce its a production site. ;)

>> what do you mean with php app?! you talk about the php VERSION (5.1.4) 
>> or do you
>> talk about the CMS (postnuke .762)?
> yeah. i'd like to see if someone can trace down the problem, and make a 
> short reproducable script.
yeah, never such an attitude with apc or at php4 with eaccelerator.

>> yep, but id love to have a more optimized and with fastcgi working
>> solution. ;)
> apc should work with fastcgi, doesn't it?
it "works" but not as fast as xcache does.
a complete page (entry) dynamicly driven without cache rendertime 
~0.8secs
a complete page (entry) dynamicly driven with APC rendertime 
~0.7-0.7secs
with xcache rendertime ~0.2-0.4secs

know what i mean? ;)

simon

> procuding not redirecting... but i have meanwhile found what happened.
> it seems xcache has problems with pnRender which is used by several cms 
> system e.g. postnuke.
thanks for your time locating the problem.
> when using xcache the first time its a MUST to clear pnRender's cache 
> AND (although it wasnt even enabled before) clearing xcache's cahce.
> since 4 hours it works without noticeble problems.
> but i keep an eye on it, snce its a production site. ;)
> 
good news, do u mean "fcgi start up" or "after xcache is enabled" by 
"first time"
i need some time(or someone) to play arround with it.

> yeah, never such an attitude with apc or at php4 with eaccelerator.

> it "works" but not as fast as xcache does.
> a complete page (entry) dynamicly driven without cache rendertime 
> ~0.8secs
> a complete page (entry) dynamicly driven with APC rendertime 
> ~0.7-0.7secs
> with xcache rendertime ~0.2-0.4secs
> 
> know what i mean? ;)
i'm pleased, but doubt that :)
did you reload the page many times and take the  average speed? pnRender 
sounds like a template engine like Smarty, which compile once and used 
repeatly. or wait for a while as your opcode cacher is getting warm up. 
it seems apc takes longer.

moo moo wrote:
>> procuding not redirecting... but i have meanwhile found what happened.
>> it seems xcache has problems with pnRender which is used by several cms 
>> system e.g. postnuke.
> thanks for your time locating the problem.
>> when using xcache the first time its a MUST to clear pnRender's cache 
>> AND (although it wasnt even enabled before) clearing xcache's cahce.
>> since 4 hours it works without noticeble problems.
>> but i keep an eye on it, snce its a production site. ;)
>> 
> good news, do u mean "fcgi start up" or "after xcache is enabled" by 
> "first time"
> i need some time(or someone) to play arround with it.
"first time" is meant as when starting the server including fcgi php 
WITH xcache. ;)

> 
>> yeah, never such an attitude with apc or at php4 with eaccelerator.
> 
>> it "works" but not as fast as xcache does.
>> a complete page (entry) dynamicly driven without cache rendertime 
>> ~0.8secs
>> a complete page (entry) dynamicly driven with APC rendertime 
>> ~0.7-0.7secs
>> with xcache rendertime ~0.2-0.4secs
>> 
>> know what i mean? ;)
> i'm pleased, but doubt that :)
> did you reload the page many times and take the  average speed? pnRender 
> sounds like a template engine like Smarty, which compile once and used 
> repeatly. or wait for a while as your opcode cacher is getting warm up. 
> it seems apc takes longer.
thats why i wrote average values. out of the cache you can half the 
numbers but even if it has to recompile or to recache again there are 
differences. pnrender is a template driven engine which includes data 
and template caching. pretty nice but has some issues with xcache. since 
many ppl use pnrender (there are tons of projects who use pnrender for 
template caching and controlling) it would be a good idea if we could 
solve this. ;)

however meanwhile i have disabled pnrender's caching system and had no 
problems anymore since. xcache if subjectively and objectively faster as 
APC. ;) eaccelerator is out of the race since it does not support php5.

Simon

> APC. ;) eaccelerator is out of the race since it does not support php5.

It does support it (eg starting with 0.9.5) ..  so you are able to 
compare them :)

Reinis Rozitis wrote:
>> APC. ;) eaccelerator is out of the race since it does not support php5.
> 
> It does support it (eg starting with 0.9.5) ..  so you are able to 
> compare them :)

well last time i read on the eaccelerator page it said that ea does not 
support php5 and is not recommended for using with php5 (eg 5.1.4).

0.9.5 is currently a release candidate. well, seems they were some 
progress in the past few months. :) have you compared ea against apc and 
xcache with 5.1.4 so far?

Simon

Simon Lange wrote:
> Reinis Rozitis wrote:
>>> APC. ;) eaccelerator is out of the race since it does not support php5.
>> It does support it (eg starting with 0.9.5) ..  so you are able to 
>> compare them :)
> well last time i read on the eaccelerator page it said that ea does not 
> support php5 and is not recommended for using with php5 (eg 5.1.4).
> 0.9.5 is currently a release candidate. well, seems they were some 
> progress in the past few months. :) have you compared ea against apc and 
> xcache with 5.1.4 so far?

On PHP 5.2 I managed to run phpinfo() with EA 0.9.5, but the real-life 
scripts made it segfault.
I ran the latest APC with 5.2-specific scripts.
Unfortunately it came out that APC is incompatible with memcached 
extension.
For now xCache 1.2.0 rc1 shows itself stable with PHP 5.2 and working in 
the stack with memcached (I did not test JSON and form validation 
modules yet).

APC Smarty gives the same speed improvement as XCache for my 
framework-based site with Smarty templates.
With optimizers on XCache is less then 1% better, without - XCache is 
less then 1% slower.
(ab, 100 requests, second-run results, Linux, Celeron)

> APC Smarty gives the same speed improvement as XCache for my 
> framework-based site with Smarty templates.
> With optimizers on XCache is less then 1% better, without - XCache is 
> less then 1% slower.
> (ab, 100 requests, second-run results, Linux, Celeron)
u can see that optimizer is not available when u're using ./configure
--help
the optimizer in XCache is a skeleton only by now... and it's good to
see optimizer is really making improvement, althought it is minor. i'll 
be start
thinking about to code the optimizer.

See http://forum.lighttpd.net/topic/3851

moo XCache wrote:
> the optimizer in XCache is a skeleton only by now... and it's good to 
> see really make improvement, which is minor though. i'll be start 
> thinking about to code the optimizer.
> See http://forum.lighttpd.net/topic/3851

It is nice. For now XCache is the only open-source product I found 
usable.
Unfortunately I am not a pro in the compilation-time optimization 
techniques.
But I can search around if you'd like.

I am writing a cluster-based project and want to create some kind of a 
Zend Platform alternative.
It will be a stack of XCache, Memcache and a heap of PHP scripts (I use 
my framework as a base).
The first goal for me is to develop a cluster-wide session management. 
It will be with data in memory, database and files (if memory is full, 
for example).
So, if I can help somehow - please tell :)

> cluster-wide session management.

Will this be open? I'm very interested!