Sommige ontwikkelaars gewoon niet leren om competent schrijf nooit in RFC. Ik heb gemerkt dat veel errror_log bestanden die enorm aantal idioten en waarschuwings-en merk had opgelopen wegens niet-PHP-normen. In het algemeen is het moeilijk te leggen aan de gebruiker, die code dat wordt overgebracht slecht is en moet worden gerepareerd. In het algemeen heb ik gemerkt dat de consument niet op error log-s na hun werkende code. In principe radicale aanpak is om volledig error_log bestanden te stoppen en die wil om ze te draaien, maar als een geheel zal ongemak voor vrij gebruikers maken. Dus draai te benaderen 2 – admin of superkrachten 1 ред bash. Zoeken naar bestanden met de naam error_log omvang meer dan 5MB (hier kostte me laat haar in haar geheel, hoewel 1MB is meer dan genoeg) en wekelijkse ze te verwijderen. Dat effect wordt bereikt door eenvoudige vind

find /home/ -name error_log -size +5M -type f -delete

Het blijft alleen om te crashen in de kroon moet worden uitgevoerd een keer per week en hebben een vrij hardnekkige beslissing. In mijn gevallen lijkt QA in 1 pm elke zondag.

0 1 * * 1 find /home/ -name error_log -size +5M -type f -delete >/dev/null 2>&1

Het is alweer een tijdje geleden dat ik over de schreef onlangs, maar ik ben vreselijk druk met mijn nieuwe job, Ik ben nog steeds geen genoegen en ik liet het internet op mijn nieuwe plek. afzonderlijk, dat hosting die mijn kleine blog gebeurde het nogal hardware ellende gehuisvest en er was een periode waarin hij niet zou kunnen functioneren als gevolg van het onvermogen mij om fysieke toegang tot de machine. Na veel nadenken heb ik besloten om mijn blogcheto openbare webserver over te dragen, beslissing die veel denkwerk en niet bijzonder gemakkelijk acceptatie vereist. Ik ben nog steeds in de eerste plaats een systeembeheerder en het raakt een groot deel van mijn trots, maar op het moment dat ik heb geen geschikte machine site wordt gehost, zodat, slikken die bittere hap en ga vooruit. Afgezien van dit feit en het feit dat ik zeer ben beperkt door de mogelijkheid van manipulatie instellingen apache + php + mysql dingen niet zo slecht. Mensen maken regelmatig back-ups hebben hun dizastar rekovari plan om technische bijstand die kunnen vragen om hulp hebben – както и се наложи за да импортират бекъпа на базата ми данни които е в скромния размер от около 1GB. За сега има още няколко дребни настройки да се довършат но това ще е като имм нерви да се боря с тъпия cpanel 😆

Voordat ik begin met de onzin ik bedoel, Ik ben niet erg vooruit met web hosting-en alles zal een ervaring die ik in het verleden heb opgedaan schrijven 2-3 maanden. Dien een aantal mooie harige VPS in opkomst als tyxo in de top 80 maar komt in de top 70 ;). Dus mijn gedachte, die nu na al die tijd heb ik wat gewoonten en zijn tot de best practices in een of andere manier komen (meestal de harde) :D. Ik zal niet schrijven of ingaan op de details van de configuratie op alle even. Eerder zal ideeën waarover te overwegen te delen.

  1. Werk de software regelmatig. Apache, php mysql alles wat je wilt Updates. Of het nu om de gaten in sigurnista patch, als gevolg van bugfixes en nieuwe functies. Houd altijd uw software up-to-date. In principe zelden aanval een server in de toepassingen meestal door gaten in de code gehost dingen te breken, maar niet te vertrouwen op deze.
  2. Apache – webserver-en u is niet wenselijk om een ​​meer actieve modules van degenen die daadwerkelijk gebruik hebben. Hoe meer modules- langzame werk.
  3. Meer gebruikers op dezelfde server – opcode cache. Enige tijd geleden schreef bovendien, titel gelukkig maken tests en de echte voordelen van deze magische. In mijn geval heb ik gekozen voor eAccelerator want in een echte werkomgeving toont het beste resultaat met alle instellingen om het te zetten. Sneller opladen minder voedsel middelen die respectievelijk betekenen dat er meer gebruikers.
  4. Druk je mensenhandel – gzip. De meest voor de hand liggende manier om het echte verkeer dat u te maken te verminderen is met gzip compressie op http reacties op de klant. mod deflate is dé oplossing voor apache. Voor andere http-server-en ik heb niet onderzocht de kwestie :). real over 50% Het viel verkeer compressie op html,css,js,xml. Ik moet om te zien of ik kon comprimeren en andere content zal interessant zijn. Omdat de foto's zijn echte inhoud die veel verkeer een site maakt.
  5. mysql Serer – Ik beveel als je niet beloond met versie 5.1 om dit te doen. Oracle hebben over het algemeen een aantal kleine ervaring met databases 😆 deze ervaring en scoorde goed in 5.1 de versie die ik heb niet geprobeerd 5.5 но и това планувам да стане скоро. Определено се ускори работата на sql заявките може би леко падна натоварването но с не повече от 5-6% maar naast, een nieuwe functionaliteit voor ontwikkelaars zijn prachtig. opgericht dergelijke scheidingswanden. Bij het upgraden voorzichtig welke instellingen je hebt in my.cfg Niet alle oude opties zijn geldig, ook goed om oude bibliotheken in ieder geval in CentOS verwijderen 5.5 veroorzaakte problemen in Debian had geen problemen. След това си вижте mysql log-а защото някои от опциите са с различни имена и е добре да ги промените ако след време минете към 5.5 да не се чудите защо не палва конфигурацията ви.
  6. sql заявките. Задължително разрешете опцията за записване на slow query. По тези дневници можете да върнете информация на програмистите ако не сте вие за бавните заявки да се оптимизират. Колкото по малко такива заявки по малко натоварване за сървъра ви 😉
  7. Малко защита – verandert de standaard poort ssh-en u zult niet crappy bots proberen om u te hacken nodig. Apache veilig met hem mod_security heel nuttig module maakt filtratie heel shitni – sql inj, RFI DDoS en andere. Zal niet stoppen groot hahor maar in ieder geval Lammert zal ziften. PHP is een goed idee om een ​​te beschermen suhosin. U kunt een verdere verlenging rechtstreeks als patch in php-code te zetten of. Ik persoonlijk de voorkeur aan de eerste van zijn schone lijkt.

Om te beginnen dit zijn dingen die te binnen schieten. Не са много а като се замисля съм направил доста оптимизации по сървъра но много от тях са доста специфични според ситуацията и няма смисъл да ги обяснявам тях като например лимитации на кешове или пък колко процеса има вдигнато apache-то. Вероятно с времето ще се сещам и за още неща които са как да кажа част от малките неща които дават големия резултат. Машината е доста добре оптимизирана за сравнение ние правим на 20к уникални посещения на ден и сме на най ниския възможен vps план load time на страниците ние не надхвърля 1,5-2 сек или ако го надхвърля е заради външните източници на реклами иначе самата страница се изплюва за части от секундата. Хора с близки позиции до нас са с не оптимизирани сървъри с доста повече ресурси от нашия и имат същите резултати. Общо взето оптимизиране му е майката и пиенето на бира бащата 😆

ps Песничката леко се връзва с тематиката 😀