Тази информация - абсорбатор за напреднали начинаещи. Контролен лист за по-напреднали е около 60 точки.

на скоростта на сайта е един от най-важните параметри. Ако даден сайт се зарежда за дълго време, посетителят просто ще напуснат сайта век, без да се изчаква изтеглянето. Google също започна да се обърне внимание на скоростта на изтегляне и понижава позицията на обекта, ако е бавен.

В общи линии, завърши перфектна оптимизация изисква много сериозен подход и участието на професионалисти, които са специализирани в това. Те са в рамките на няколко дни проучване на тясното пространство на сайта и да ги коригира. Но има и много бързи и прости техники, които ще ви помогнат да диша по-свободно уебсайт. Не е задължително да използвате всички на техниките, изброени по-долу, опитайте се всеки и да видим как това се отразява на скоростта на сайта.

Има две готини инструменти, за да проучат скорост на сайта си - YSlow и GTmetrix. те трябва да се използва след всяко изменение. Напишете ключовите параметри за измерване (за зареждане на страницата, размер на страницата, броя на исканията за HTTP и общата оценка в точки) в предната част на всяка модификация, за да бъдете сигурни, че се движим в правилната посока. Можете също да опитате и JMeter Apache Bench.

kosHta написа:
насочена към програмисти?

след като започва да се развива останалата част от пръстите в Drupal, той започна да става по-лесно. Искам да кажа, че просто искаш да отнеме и това, което трябва, а не четене на интернет грамадата 2-3 инсталирането на модулите, опитайте се да разберете как работят, а защо не направите това, което искате, или не прави това. И ако се съди по това как тя е там всичко е подредена, а броят на kontriba - струва ми се, че е направил така, повече за програмисти.

Дебютантка написа:
Много странно модул. В съхранение на файлове muskla по-добре? Вземане на проби от първичния ключ в muskle работи много бързо. Накратко за ползите от такъв модул е ​​изключително съмнителни.

в MySQL проблеми с производителността след 20MB / сек на трафика (в от базата данни)
ИЗГЛЕДИ - това генерира трафик. И толкова повече идеи, които имате и повече данни за трафика.
В действителност се оказва, че по-голямата част от времето се изразходва за получаване на тези данни от базата данни, а не в техния избор.
В резултат на това, когато се прехвърля от файловия кеш, натоварване отива на диск системата на МО, че е по-добре, разработени за такива натоварвания.
В действителност е разликата между "IO мрежа + IO на база dannyhh файл" и "IO на диска." Това ви позволява да запишете работата на база данни за използването по предназначение, вместо за съхраняване на кеша.

Освен това, можете да съхранявате на кеша в Memcached но да го инсталирате на по-голямата част от уеб Силите не са налични или изисква известни познания за потребителя.
Отново с помощта на Memcached кеш памет за съхранение. Тя е по-скъпа от дисково пространство.
Вече има нужда да търсите за конкретен проект.

Докато използването на filecache (cacherouter) дава мигновени резултати.
На примера на разходите за хостинг DH.Elastic попада в пъти за клиента.

"Проблеми с производителността на базата данни да се появят след 20 МБ / сек на трафика (в от базата данни)"
Това просто не е така. Това зависи от мрежата, желязо, създаване на ITP Т.е. Тази фраза, в действителност представлява един конкретен случай, и не е свързана с никакви MySQL. Той няма никакви такива архитектурни ограничения. Във вашия конкретен случай, тя работи така не повече.

IO не може да бъде най-малко, например, ако сървърът на базата на същия сървър, режийните е много малка, когато се работи чрез контакти в мрежата. Или размера на диск латентност и база на мрежата може да бъде по-малък от забавянето на диск с файлове, които могат да бъдат местни, и, освен това, не бърза.

Или мрежови забавяния, които потискат всички с голям брой заявки (а не на трафика, между другото, на първо място), може да има много малки.
Или кеш на файловата система може до известна степен размити, и ще бъде лудост поставени на кеша.
Или, като специален случай, в кеш на файловата система, просто не е достатъчно лява памет.

Тегло на случаите, когато кеша към базата данни ще бъде по-добре в края на краищата.
И ако в някакъв си хостинг и вашия тарифен този случай работи добре, и ви позволява да запазвате, струва си да го напиша и в описанието на тази тарифа е най-вероятно няма да бъдат изтъквани като най-добрият вариант при всички случаи.

Обобщение на тема: Да кеш файл по-добре. В действителност, това не е толкова често. Disk IO на повечето уеб Силите е пречка, особено на не-скъп VPS.

ttenz написа:
производителност кеширане е много готино нещо

Ситуация. Галерия с безкрайна превъртане на vyuvz. Thumbnails изчезват (всеки път на различни места), когато страницата се презарежда. А подкрепа хостинг посъветвани да включва кеширане vyuvz. Визуализациите започнаха да изчезват в пълния смисъл на думата. Какво ще посъветвате?

Ново във форума

Съдържанието на този сайт са публикувани при условията на Криейтив Комънс Признание-Споделяне на споделеното 3.0 или по-
Софтуерните кодове в текста на статиите - на GNU GPL v2 среда или по-късно.
Drupal - Dries Buytaert търговска марка