So tell me.. Server optimisation

[Soniceffect]

So then guys, I would like some info if anyone is willing?

Basically I would like to know the difference between the different caching and optimizations you can use and which you would recommend/why.

I know you can use some of them together, but I dont know which ones, such as memcache, xcache, eaccelerator etc. I currently have memcache running on my server on another site which seems to do well however I wanna understand it all.

Also how are these set up on IPB? Can you set up more than one?

Are the any recommended settings for servers? (I appreciate this is a difficult question to answer) I am using 1&1 dedicated cloud server with 6 cores and 8gb memory available. I do run a couple of other sites, however these are small and insignificant in the grand scheme of things. The server is primarily for my forum.

[Grumpy]

The topic you're asking is something that could be written and made into a book. It's not a valid request to be making in a forum beyond very simple overviews -- for which you could easily google for.

Simple rule of thumb for your memcache/xcache/eaccelerator/apc:

Do you have 1 server? Then pick xcache OR apc for caching and php compilation optimization. Why? Because they're meant for such case.

Do you have many servers? Then pick (xcache OR apc or php optimize) AND memcache for caching. Why? Because they're meant for such case.

When should you use eaccelerator? You're an ea fan. Why? Because ea is deprecated.

You can see how they're implemented on IPB here:

http://community.invisionpower.com/resources/guides.html/_/advanced-and-developers/api-methods/kernel-caching-libraries-classcachephp-r153

Only one is supported by IPB as default, though it's possible for you to alter (obviously since you can change IPB source and everything...). IPB configuration covers caching only.

Are the any recommended settings for servers?

Canonical recommendation? no.

1&1 dedicated cloud server

Random recommendation, but switch out asap... This is a company where trying to find a real (non-affiliate) positive review is near impossible. You can find plenty of terrible though...

Rule of thumb on hosts to avoid: Any company that has more marketing budget than actual budget on technical aspects of hosting + support. That includes:

1&1, godaddy, and everything under EIG.

[Soniceffect]

The topic you're asking is something that could be written and made into a book. It's not a valid request to be making in a forum beyond very simple overviews -- for which you could easily google for.

Simple rule of thumb for your memcache/xcache/eaccelerator/apc:

Do you have 1 server? Then pick xcache OR apc for caching and php compilation optimization. Why? Because they're meant for such case.

Do you have many servers? Then pick (xcache OR apc or php optimize) AND memcache for caching. Why? Because they're meant for such case.

When should you use eaccelerator? You're an ea fan. Why? Because ea is deprecated.

You can see how they're implemented on IPB here:

http://community.invisionpower.com/resources/guides.html/_/advanced-and-developers/api-methods/kernel-caching-libraries-classcachephp-r153

Only one is supported by IPB as default, though it's possible for you to alter (obviously since you can change IPB source and everything...). IPB configuration covers caching only.

Are the any recommended settings for servers?

Canonical recommendation? no.

1&1 dedicated cloud server

Random recommendation, but switch out asap... This is a company where trying to find a real (non-affiliate) positive review is near impossible. You can find plenty of terrible though...

Rule of thumb on hosts to avoid: Any company that has more marketing budget than actual budget on technical aspects of hosting + support. That includes:

1&1, godaddy, and everything under EIG.

I understand I can google, however wanted peoples opinions with regards to IPB specifically. And when is good to use a combination caching (if at all).

Actually 1&1 on cloud is extremely good. It is practically a dedicated machine environment and I switched to them from a dedicated box. The service from their departments is rubbish granted, there panel is rubbish granted, as is there shared hosting and vps services, however the cloud hosting is not by any means and performs extremely well with my big board currently on vbulletin (which is what I am looking at using).

I am not by any means an amature with regards to hosting. I am just an amatuer with regards to dedicated hosting and setting things up correctly myself. Although that said I have optimised my mysql processes, and my apache config (which I was actually contemplating switching out tbh).

Incase your interested btw, I have had only 1 experience of downtime in 18 month of 1&1 cloud when pretty much all of 1&1 went down worldwide. Other than that I have never needed to contact support for anything due to it being fully self managed. I think this makes a bit difference and would never touch any other 1&1 product with a barge pole.

EDIT: Sorry quite rude of me.. Thankyou for taking the time to respond :)

[Grumpy]

Don't really want to steer the topic to about 1&1... but the "bad support" is really the #1 reason even if you have an unmanaged account. Because the worst nightmare stories I hear about 1&1 is how they butcher their customers on administration and then can't resolve. Starting from charging for non-existent servers to always going to collections...

On the topic, IPB isn't really that special when it comes to optimization. Pretty much the same step as majority of other sites.

1. ditching apache for something faster (like nginx, etc) to serve static content (at least). There are so called "apache experts" who swear there's nothing faster than apache for php handling. But even if they're right, apache still sucks because apache has a hard time tuning between static and dynamic. You'll get a looser in one of the two eventually.

2. ditching mysql for mariadb/etc (not as significant, though scenario dependent)

3. installing php optimizers (apc/xcache/ea -- the difference between apc and xcache is hardly even measurable. both popular and stable.)

4. Installing user caches (apc/xcache/memcache)

5. Optimizing mysql settings - Though, one potential pitfall here for IPB. Don't set a very high table cache. IPB has lot of text/blobs that setting a very high table cache will have a negative effect. It will thrash a lot. Noticed this personally. But, I'm assuming most people won't set it that high to begin with unless they have a dedicated db server.

6. Optimizing source (IPB in this case) by editing source to meet your custom needs.

7. Optimizing sql engines for uses ( -> innodb/memory/etc)

7.1 innodb when high writes.

7.2 memory when high usage but acceptable volatility (ie sessions)

[Soniceffect]

Don't really want to steer the topic to about 1&1... but the "bad support" is really the #1 reason even if you have an unmanaged account. Because the worst nightmare stories I hear about 1&1 is how they butcher their customers on administration and then can't resolve. Starting from charging for non-existent servers to always going to collections...

On the topic, IPB isn't really that special when it comes to optimization. Pretty much the same step as majority of other sites.

1. ditching apache for something faster (like nginx, etc) to serve static content (at least). There are so called "apache experts" who swear there's nothing faster than apache for php handling. But even if they're right, apache still sucks because apache has a hard time tuning between static and dynamic. You'll get a looser in one of the two eventually.

2. ditching mysql for mariadb/etc (not as significant, though scenario dependent)

3. installing php optimizers (apc/xcache/ea -- the difference between apc and xcache is hardly even measurable. both popular and stable.)

4. Installing user caches (apc/xcache/memcache)

5. Optimizing mysql settings - Though, one potential pitfall here for IPB. Don't set a very high table cache. IPB has lot of text/blobs that setting a very high table cache will have a negative effect. It will thrash a lot. Noticed this personally. But, I'm assuming most people won't set it that high to begin with unless they have a dedicated db server.

6. Optimizing source (IPB in this case) by editing source to meet your custom needs.

7. Optimizing sql engines for uses ( -> innodb/memory/etc)

7.1 innodb when high writes.

7.2 memory when high usage but acceptable volatility (ie sessions)

Ace reponse!! :smile:

With regards to 7.x . Is there any standard set of rules people are tending to follow with regards to this. I have innodb set up etc, however not knowing the database structure (YET lol) makes it difficult to accertain usage without waiting till it has been running on my site for a while. Would like to get it set up as optimally as I can before going live with it (although I appreciate there will still be tweaking going on afterwards, just want to launch it as good as I can do).

Incidentally have put apc on for caching on my test install and certainly makes a decent impact. Was going to go for xcache, however with APC being part of PHP now figured its likely to be updated with it as it goes along.

Also this is may sound a daft question (however Im coming form vbulletin LOL) but is php 5.4 supported by IPB?

[Codehusker]

The only table I would put in memory is sessions. It's heavily accessed, and everything will be fine if that table is lost.

Regarding InnoDB, some would only switch tables like posts. Personally, I have all tables except sessions as InnoDB. This is particularly beneficial if you're using MariaDB or Percona, which both have InnoDB-specific optimizations. Going down this path, you have to set up sphinx for search.

PHP 5.4 is fully supported.

[Soniceffect]

The only table I would put in memory is sessions. It's heavily accessed, and everything will be fine if that table is lost.

Regarding InnoDB, some would only switch tables like posts. Personally, I have all tables except sessions as InnoDB. This is particularly beneficial if you're using MariaDB or Percona, which both have InnoDB-specific optimizations. Going down this path, you have to set up sphinx for search.

PHP 5.4 is fully supported.

Thankyou for this very much appreciated...

Why btw would you have to have sphinx for search when using INNODB? IMO should work just the same and only reason to use sphinx is if you have a particularly large post count (whichI do so will probably think about it anyways lol) but just curious as to the reasoning as may well change my understanding.

[Luis Manson]

5. Optimizing mysql settings - Though, one potential pitfall here for IPB. Don't set a very high table cache. IPB has lot of text/blobs that setting a very high table cache will have a negative effect. It will thrash a lot. Noticed this personally. But, I'm assuming most people won't set it that high to begin with unless they have a dedicated db server.

Do you mind to elaborate on which table cache would you tune?

[Codehusker]

Why btw would you have to have sphinx for search when using INNODB? IMO should work just the same and only reason to use sphinx is if you have a particularly large post count (whichI do so will probably think about it anyways lol) but just curious as to the reasoning as may well change my understanding.

Regular search utilizes fulltext indexes on certain columns, which InnoDB doesn't support.

The InnoDB engine included in MySQL 5.6 does support fulltext indexes, but 5.6 isn't stable yet. Likewise, MariaDB 10 will have fulltext InnoDB, but also is unstable.

[Soniceffect]

Regular search utilizes fulltext indexes on certain columns, which InnoDB doesn't support.

The InnoDB engine included in MySQL 5.6 does support fulltext indexes, but 5.6 isn't stable yet. Likewise, MariaDB 10 will have fulltext InnoDB, but also is unstable.

Ahhh .. Cheers :)

[Grumpy]

Do you mind to elaborate on which table cache would you tune?

I'm sure the exact numbers will vary depending on your system and your forum usage, but one to avoid an extremely high cache values are:
table_open_cache
tmp_table_size
max_heap_table_size
as I noticed a detrimental result of having high values. I can't really tell you what to tune or in what direction -- again, because of dependency on other factors. And my IPB instance isn't exactly an average setup either.









WTF is wrong with this text box...? It keeps on adding /quote's.

[Soniceffect]

Grumpy, on 17 Jan 2013 - 18:25, said:

I'm sure the exact numbers will vary depending on your system and your forum usage, but one to avoid an extremely high cache values are:

table_open_cache

tmp_table_size

max_heap_table_size

as I noticed a detrimental result of having high values. I can't really tell you what to tune or in what direction -- again, because of dependency on other factors. And my IPB instance isn't exactly an average setup either.

WTF is wrong with this text box...? It keeps on adding /quote's.

Think your name should be changed to "quotaholic" LOL

[Soniceffect]

Thankyou for your insight on these guys .... Forum now up and running on IP.Board and runnin like dream ;)