Anyone using Litespeed?

[Gary.]

Your missing the pont.

Read here - I also use something like this:

http://www.litespeedtech.com/support/forum/showpost.php?p=14399&postcount=21

This is a litespeed topic you know...... :unsure:

By also doing the above I saw CPU dropped a HUGE amount - Now with the cron cleaning every 4 mins I hardly use any memory. And CPU is, erm, Idle...

[Cap'n Refsmmat]

Right. tmpfs is memory-based storage. What you're doing is telling eAccelerator to use a disk-based cache, then giving it a disk location that is stored in shared RAM, then clearing its cache because the tmpfs is size-limited.

What's the point? You could just tell eAccelerator not to use the disk cache at all, and let it use RAM. In that case, you can specify a maximum RAM usage based on your server's memory capacity, and eAccelerator will intelligently discard old cache entries to stay within that limit.

You're finding a way to get eAccelerator to cache opcodes in RAM and hacking in a quota by clearing its cache, rather than letting it use its own RAM-based cache with an intelligent and efficient usage quota already in place.

You should just set shm_only = 1 and set the shm_size to the appropriate size for your system. eAccelerator will cache everything in RAM.

Now, I suppose tmpfs is useful in one case: if you're running more than one PHP parent process in FastCGI. In that case, there will be more than one eAccelerator memory cache, and the contents will be duplicated. But this can be replicated by using one PHP parent and more child processes.

[Gary.]

Your last 3 lines basicly said everything I have and have done.
tmpfs does help a HUGE amount :)

[Cap'n Refsmmat]

That's why I run 1 PHP process with 9 children. Saves the duplication and the effort. Of course, I use xcache instead...

[Zhana]

No one using memcache?

[Cap'n Refsmmat]

I run memcached along with xcache. memcached records 20-40 requests per second but unfortunately only about 150kB of data stored. It'd be great if more data were stored in memcached -- I've got 64MB of space allocated to it. IPS ought to consider what other data can be chucked in memcached.

[shamil]

I run memcached along with xcache. memcached records 20-40 requests per second but unfortunately only about 150kB of data stored. It'd be great if more data were stored in memcached -- I've got 64MB of space allocated to it. IPS ought to consider what other data can be chucked in memcached.

Remember that memcache is a memory system, designed to store objects - thus it can be used to store phrases, images etc. There's a lot that can be stored there.

[Cap'n Refsmmat]

Remember that memcache is a memory system, designed to store objects - thus it can be used to store phrases, images etc. There's a lot that can be stored there.

Yes. And by default, IP.Board doesn't store all that much there. I wonder if things like post and signature caches could be dumped in memcached as well.

I was going to use it for my WordPress MU datastore as well, but last time I tried I ended up with the blogs getting messed up with 404s and I didn't have time to diagnose it.

[shamil]

Yes. And by default, IP.Board doesn't store all that much there. I wonder if things like post and signature caches could be dumped in memcached as well.

I was going to use it for my WordPress MU datastore as well, but last time I tried I ended up with the blogs getting messed up with 404s and I didn't have time to diagnose it.

I suppose signatures could, but I'm wary about posts - maybe stickies only, or caching of 1 forum e.g. announcements.

[Cap'n Refsmmat]

Why? IP.Board already caches parsed posts in content_cache_posts.

[wepfijweoifj]

It's amazing! idreamofjimmy.info and that's on a shared server.

[shamil]

Just to compare, how is this site, compared with the one above, speed wise?

http://www.radonsystems.net/forum/

vs

idreamofjimmy.info

[Gary.]

If you want to test just ping the website itself, The skin could be causing a slow issue or lots of mods and such.
Ping is simple here are my stats and the stats for that domain:

Pinging www.radonsystems.net [67.231.251.111] with 32 bytes of data:

Reply from 67.231.251.111: bytes=32 time=219ms TTL=207

Reply from 67.231.251.111: bytes=32 time=219ms TTL=207

Reply from 67.231.251.111: bytes=32 time=219ms TTL=207

Reply from 67.231.251.111: bytes=32 time=220ms TTL=207

Ping statistics for 67.231.251.111:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 219ms, Maximum = 220ms, Average = 219ms

Pinging MY_DOMAIN_WAS_HERE.co.uk [1*8.**.95.**] with 32 bytes of data:

Reply from 1*8.**.95.**: bytes=32 time=21ms TTL=23

Reply from 1*8.**.95.**: bytes=32 time=25ms TTL=23

Reply from 1*8.**.95.**: bytes=32 time=21ms TTL=23

Reply from 1*8.**.95.**: bytes=32 time=21ms TTL=23

Ping statistics for 1*8.**.95.**:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 21ms, Maximum = 25ms, Average = 25ms

Now my server is located in france, Ad that other one usa, As you can see the HUGE time difference, Hense the reason I stay from USA servers lol.

[shamil]

If you want to test just ping the website itself, The skin could be causing a slow issue or lots of mods and such.

Ping is simple here are my stats and the stats for that domain:

Now my server is located in france, Ad that other one usa, As you can see the HUGE time difference, Hense the reason I stay from USA servers lol.

I know - unfortunately, the majority of my clients are in the US. However, I'll be putting a server at OVH to reduce these ping times.

[Bono]

If you want to test just ping the website itself, The skin could be causing a slow issue or lots of mods and such.

Ping is simple here are my stats and the stats for that domain:

Now my server is located in france, Ad that other one usa, As you can see the HUGE time difference, Hense the reason I stay from USA servers lol.

USA servers are fine if you pick right dedicated provider. Pick something on east coast and you would have ping around 90ms. I got from east europe to east coast 110ms which is decent and OVH is only good inside of their network and Europe, rest is bad.

[hawksfan]

I've installed the 15 day trial on my VPS yesterday. I've only got a test forum up on the vps so far so I can't truly gauge it yet (although by the seat of the pants it does feel much snappier). The stats at the bottom of the test forum have really improved vs. what they were with Apache. On Apache it would always read at least .1-.15 (I don't think that I ever saw it go lower than that), & depending on the page would spike over 2.4 (yes 2.4, not .24). With LS I've seen it as low as .015, & the highest that I've seen is .28. I can't wait to move the live site & see how it performs.

Any advice for tweaking or configuring LS? I'm on a fully managed vps, so the host took care of the install & setup for me. I just had to build the php binary & then make the actual switch in WHM, but I haven't done anything beyond that.

[MarcusInMd]

Your missing the pont.

Read here - I also use something like this:

This is a litespeed topic you know...... :unsure:

By also doing the above I saw CPU dropped a HUGE amount - Now with the cron cleaning every 4 mins I hardly use any memory. And CPU is, erm, Idle...

I decided to give this a whirl (however my eaccelerator install was already pretty much optimized except for this "trick")

Made no difference what so ever on the server load. None, nada, nothing. It didn't appear to hurt anything so I will keep it like this for now.

[Gary.]

It should do ALOT !

Have you checked to see if any cache files are being made ? If not then something is not right, If done right you should see this folder fill up untill the crontab runs.

Use my way.. Runs good. Please remember this though, Don't blame me if you mess things up !

SSH:

mkdir /dev/ea

chmod 777 /dev/ea

Edit /usr/local/lib/php.ini

change this line

eaccelerator.cache_dir="/tmp/eaccelerator"

to

eaccelerator.cache_dir="/dev/ea"

Now

eaccelerator.shm_size="16"

Change to eaccelerator.shm_size="1"

This will stop many many memory building up.

Edit your crontab:

nano /etc/crontab

add

0 */1 * * * root rm -rf /dev/ea/*

save and restart crontab service:

/etc/init.d/crond restart

restart php:

service httpd restart

wait for 5 mins...... 5...4...3...2...1...

cd /dev/ea

ls -la

Do you see any files ? If so then its working ! The crontab I mentioned above should flush the folder every 1 hour with the settings I mentioned.

[MarcusInMd]

Well eaccelerator has been creating cache files on my server since I set it up about 5 years ago. What I did was the tutorial from the litespeed link you provided. Now it creates the cache files inside of /devs/ folder however, what I am saying is I did not see any improevment in server load from creating and deleting vs. the old way I was doing it. I will keep watching it but so far nada.

[Gary.]

remove the contents of the folder and then wait a further 5 or 10 mins to see if it re-caches anything, If not then its probably the folder not writable nor the module is not functioning properly.

Restart apache, then check if the module is running:

php -v

You should see a performance increase, We have optimized many servers and all have good results using opcode.

[MarcusInMd]

It's creating cache files. It just has not made any speed difference.

[Gary.]

There must be some other OPcode in place also doing the same job then. Nothing to worry about :)

[Zhana]

All those who are running Litespeed, what about mod_rewrite? Does it works off the bat or you have to tweak .htaccess or any other things?


Thank you.

[Bono]

All those who are running Litespeed, what about mod_rewrite? Does it works off the bat or you have to tweak .htaccess or any other things?

Thank you.

Works out of the box...you don't have to modify anything.

[Zhana]

Cool cool, how much are you paying for it bono?