Some programmers will simply never learn to write fluently in RFC. I noticed a lot of errror_log files in which a huge number of stupid warnings and notices for non-compliance with PHP standards had accumulated.. In general, it is difficult to explain to the consumer, that the code he put is naughty and needs to be fixed. In general, I've noticed that users don't care about error logs after their code works. Basically, a radical approach is to completely stop the error_log files and who wants to play them, but in general it will create discomfort for many users. That is why I am stepping up to an approach 2 – admin superpowers or 1 red bash. Search for files named error_log larger than 5MB (here I leave my value higher even though 1MB is more than enough) and deleting them weekly. The effect in question is achieved elementary with find
find /home/ -name error_log -size +5M -type f -delete
All that remains is to run into a crown to be performed once a week and we have a very persistent solution. In my case it seems ok in 1 hours every Sunday.
It's been a long time since I last wrote but I'm terribly busy with my new job, I haven't settled in yet and I haven't put the Internet in my new place. Separately, that the hosting where my small blog was located had a lot of hardware problems and there was a period in which it could not function due to my inability to have physical access to the machine. After much thought, I decided to transfer my blog to a public web server, a decision that required a lot of thinking and not a very easy acceptance. After all, I'm primarily a system administrator, and that strikes my pride a lot, but at the moment I don't have any suitable machine to host the site like that, that I swallow the bitter bite and move on. Excluding this fact and the fact that I am extremely limited by the possibility of manipulating the settings of apache + php + mysql things don't look so bad. People make regular backups have their disaster recovery plan have their technical help you can ask for help – както и се наложи за да импортират бекъпа на базата ми данни които е в скромния размер от около 1GB. За сега има още няколко дребни настройки да се довършат но това ще е като имм нерви да се боря с тъпия cpanel 😆
Before I start with the nonsense, I want to say, that I am not very advanced with web hosting and all I will write is the experience I have gained in recent times 2-3 months. I administer a fairly busy VPS in terms of traffic, according to tyxo is in the top 80 but enters the top 70 ;). That's my thought, that after so long I have acquired various habits and reached good practices in one way or another (usually more difficult) :D. I will not even write or go into the details of the configuration at all. Rather, I will share ideas to think about.
Update the software regularly. Apache, php mysql all wants updates. Whether to patch holes in the security, whether due to fixed bugs or new features. Always keep your software up to date. In general, it is rare to drill a server through the applications, usually through holes in the code of the hosted things, but let's not rely only on this.
Apache – it is not desirable for your web server to have more active modules than the ones you actually use. The more modules on- slow work.
Multiple users on the same server – opcode cache. Some time ago I wrote Besides zerdion do satisfactory tests and see the real benefits of this magic. In my case I chose eAccelerator because in a real working environment it shows the best results with all the settings to it. Faster loading with less eating resources, which means more users.
They push you with traffic – gzip. The easiest way to reduce the real traffic you make is with gzip compression of http responses to the client. Mod deflate is the apache solution. For other http servers I have not researched the issue :). Real around 50% I lost traffic when compressing on html,css,js,xml. I need to see if I can compress other types of content as well. Because real photos are the content that makes the most traffic in a site.
mysql serer – I highly recommend it if you haven't been awarded a version 5.1 to do it. In general, Oracle has some small experience with databases 😆 and this experience has put it well into 5.1 version I have not tried 5.5 но и това планувам да стане скоро. Определено се ускори работата на sql заявките може би леко падна натоварването но с не повече от 5-6% but also the new functionalities for the programmers are wonderful. The basic one partitions. When upgrading, be careful what settings you have in my.cfg Not all old options are valid, it's also a good idea to remove old libraries at least with CentOS 5.5 made problems with Debian I did not have such annoyances. Then look at the mysql log because some of the options have different names and it is good to change them if you go to 5.5 don't wonder why your configuration doesn't work.
sql заявките. Задължително разрешете опцията за записване на slow query. In these logs you can return information to the programmers if you are not for slow requests to be optimized. The fewer such requests the less load on your server 😉
A little protection – change the default port of ssh you don't need crazy bots to try to hack you. Apache secure it with mod_security quite a useful module makes filtering on quite a bit – sql inj, rfi DDoS and others. It won't stop a lot of fuss, but at least the lamers will weed them out. PHP is a good idea to protect with Suhosin. It can be put as an additional extension or directly as a patch in the php code. I personally prefer the first one I think is cleaner.
For starters, these are the things I can think of. They are not many and when I think about it I have done a lot of optimizations on the server but many of them are quite specific according to the situation and there is no point in explaining them such as cache limits or how many processes the apache has been raised. Probably in time I will think of more things that are how to say some of the little things that give the big result.. The machine is quite well optimized for comparison we make 20k unique visits per day and we are on the lowest possible vps plan load time on the pages we do not exceed 1,5-2 sec or if it exceeds it is due to external sources of ads otherwise the page itself spits out for fractions of a second. People close to us have non-optimized servers with a lot more resources than ours and have the same results. In general, his mother is optimizing and her father is drinking beer