Оптимизация на динамични сайтове и скриптове
Не, този път няма да пиша за SEO оптимизация, както обикновено, а за един друг вид оптимизация, която пренебрегваме още по-често – оптимизацията на кода на даден сайт или скрипт. Тя е също толкова важен елемент от успеха на един сайт, колкото е и SEO оптимизацията.
Повечето хора си качват сайтовете на така популярния и удобен „споделен хостинг“. Но този хостинг е споделен и трябва да се спазва определена култура, когато се използва. Различните сайтове използват споделени ресурси и когато един сайт товари повече и заема повече памет, то това се отразява на всички други.
Рядко се налага един сайт да има толкова много потребители и изчислителни нужди, че да се наложи да работи на VPS или на собствен сървър. Последните ми разработки около referring sites скрипта ми доказаха, че един сайт с много изчисления и потребители може да се оптимизира и да хаби ресурси колкото обикновен блог.
Хората рядко мислят за оптимизация на програмите си. В днешния свят на постоянно развиващи се технологии, сякаш може с малко по-скъп хардуер да се подкара всяка една програма. В същност не е така – когато даден сайт започне да прави значителен брой посещения – тогава проблемът с ресурсите може да се реши само чрез оптимизация на скриптовете му.
Ето и някои основни принципи, без да се задълбавам:
1. Използване на функции, изискващи по-малко ресурси.
Примерно в PHP е много по-ефективно да се използват функциите strpos() и strstr() за търсене на низ в текст, отколкото функцията preg_match(). Последната е проектирана за регулярни изрази и заема много повече памет и ресурси. Проверявайте за всяка функция какво прави и дали няма по-добра алтернатива.
2. Минимизиране на връзките към базата данни.
Това може би е най-често срещания проблем при разработка на уеб скриптове – големият брой връзки към базата данни. Често начинаещите програмисти извикват връзка всеки път, когато им е нужна дадена информация. В повечето случаи има начин необходимата информация да се вземе предварително и наведнъж, и да не се занимава допълнително SQL сървърът.
3. Използване на индекси (кеширане) на SQL ниво.
Повечето системи за обработка на бази данни, като MySQL, поддържат така нареченото кеширане на колони. То е полезно, когато ще търсим в дадена колона или ще сортираме по нея. Примерно, ако имате колона client и често Ви се налага заявка от вида: „SELECT * FROM clients WHERE client LIKE ‘%Ivanov’“, то добавете индекс към client.
4. Кеширане на информация с цел избягване на повторни заявки
Става въпрос за класическото кеширане, при което примерно създаваме отделен HTML за всяка страница и го качваме на сървъра. При следващо извикване на съответната страница, не товарим базата данни със заявки, а просто зареждаме кешираното копие. При промени в скрипта, всичко се кешира на ново, което е много по-оптимизиран процес.
5. Използване на бази данни в трета нормална форма
Това е малко по-сложно за кратко обяснение, но идеята е да има повече малки таблици с външни ключове между тях. Целта е да се избягват служебно празни полета и/или повтаряне на данни в дадена колона. Така се пести място и многократно се ускорява работата на системата. В MySQL външни ключове се правят при основа InnoDB.
6. Използване на PHP или сървърния скрипт само където е необходимо
Може цяла една HTML или друга страница да се генерира чрез PHP, примерно, но това изисква много повече функции и ресурси. Изглежда и по-сложно. Затова сървърният скрипт трябва да се използва само там, където наистина има нужда от него. Примерно, за изписване на текст не е нужно да викате echo „Ала бала“;, а е достатъчно да си напишете текста.
7. Избягване на типове като BLOB в SQL системата
Много често с цел улесняване на дадена задача, ни е по-лесно да качим дадена снимка или видео директно в базата данни в бинарна форма. Това обаче е страшно натоварващо за системата. Много по-ефективно е да качим снимките/видеотата в директория и в базата данни да пазим само връзки към тях. А BLOB се използва само когато няма друг начин.
Това са основните моменти, за които се сетих. Разбира се, няма как да съм изчерпателен. Оптимизацията си е цяло едно изкуство, но винаги може да се оптимизира повече. Въпросът е къде е разумната и приемлива граница. Чрез избягването на най-често срещаните грешки се вдига ефективността многократно. Тук описах повечето от тях.
Коментари
17 коментара за Оптимизация на динамични сайтове и скриптове
-
Оптимизация на код за чт, 13th ное 2008 11:57
[...] на динамични сайтове и скриптове (или кода на сайт) Оптимизация на динамични сайтове и скриптове Оптимизация за търсачки на Wordpresswordpress идва с няколко [...]
-
Много полезна тема, само, че wp не е пример за оптимизирана работа :)
WP товари доста хоста и има мноооого заявки към сървъра.
Аз си правих с екперименти с include и ако се include-ва цялото url – товари адски много повече от просто include „file.php“ .
И ако напишеш примерен код за
4. Кеширане на информация с цел избягване на повторни заявки
ще е най-полезното ми четиво :) -
WordPress е ясно, че не е пример за добър CMS откъм код, но път е перфектен откъм SEO :) Едното за сметка на другото. При малки блогове върши работа. За големите си има plugin за кеширане, който мене много ме дразни, но друг начин няма.
А пример по точка четири е трудно да дам, защото всичко си е строго индивидуално. Има безброй много начини за кеширане. Най-лесното е да се кешира резултатът от сложни заявки в други други SQL таблици, но пак си остава проблемът с броя на конекциите.
-
Това ме вдъхновява да понапиша такова ръководство за asp.net като там за performance-а са ясни нещата, но пък за SEO има какво да се каже. И малко градивна критика, никога не съм чувал че създаването на индекси в базата може да се сравни с кеширане.
-
Много добър материал. Браво! :)
-
@Nikolay- Индексите, до колкото знам, са си точно кеширане – извлича се дадена информация от колоните, записва се в определен ред (ако има някаква логика за това) и после при извикване се използва именно този кеш, за да не се хаби време да се вика реалната заявка. Поради тази причина не се прави index на всички колони, защото при всяка една промяна на базата трябва да се актуализира много повече кеширана информация, което ще обезсмисли индексирането.
-
Браво за статията, макар и накратко много добре засяга всички основни теми свързани с подобен тип оптимизация.
Към точка 4 мога да добавя, че в случая за подобно кеширане е добре да се озползва директно include() на файла вместо fopen() примерно. По-малко товари. -
@Васил Тошков – индексите НЕ са кеширане, а индексиране … ако бяха нямаше да се казват индекси,а кешове … mySQL си има отделна система за кеширане на заявки и ИНДЕКСИ … можеш да ги видиш с нещо като:
show variables like ‘%cache%’;
http://dev.mysql.com/doc/refman/5.0/en/myisam-key-cache.html
поради тази причина т.3: „Използване на индекси (кеширане) на SQL ниво.“ не трябва да съдържа „кеширане“.
Под кеширане трябва да напишеш нещо за have_query_cache:
http://dev.mysql.com/doc/refman/5.0/en/query-cache.html -
uhaaa.com за пт, 14th ное 2008 09:02
Оптимизация на динамични сайтове и скриптове…
Не, този път няма да пиша за SEO оптимизация, както обикновено, а за един друг вид оптимизация, която пренебрегваме още по-често – оптимизаци…
-
Иднекси – кеширане, няма значение термина. Важното е хората да схванат идеята :)
-
Правили ли сте SEO за електронен магазин (стоки) и Оптимизация на скриптове каквато е темата? Как се постъпва в този случай? PHP ли е най удачния език за двете оптимизации?
-
Едва ли езикът има някакво значени са оптимизацията и/или SEO оптимизацията. Не мога да разбера точно какъв ти е въпросът относно електрнонния магазин?
-
Има значение защото ако имаш 2 -3 нива на категории и на последно артикули се получава дублирано съдържание.. Няма как да се избегне и се налагат по специални методи. Примерно аз пиша на PERL и в CGI-bin сkрипта няма как да се индесксира което не мисля че е минус а с PHP трябва ад се спазват хиляди правила. Да не говорим за бързодействие. Като цяло WP e страхотно бъгав да не говорим за плъгините. Не мога да го използвам за истински комерсиални цели. Да може да се изпшолзува за CMS но свете не е само пост
И така оптимизацията е троина първо скриптове, после съдържание и на края архитектура.+ sys admin това ме интересува? -
drJeckyll, много си прав. Един от основните проблеми при много известни CMS като Joomla например. Ела да видиш ако имаш в една категория 10 или 20 хиляди новини за какъв индекс иде реч и какви заявки. Де да миниваха през кеша. Естественото решение би било CMS на повече нива с кеширане на индексите, тъй като не е много уместно да направиш 200 подкатегории в само една категория на сайта.
Васил Тошков, статията е полезна, но с лош замисъл според мен. Ако е за начинаещите потребители – много е сложна, за тях трябват някакви гайдчета или препоръки от рода на: свали тоя модул, инсталирай го… линкче. Включи това, избягвай другото…
От друга страна – напредналите програмисти дето пишат на ръка цели CMS-и ще кажат, че е поредната статия демонстрация на Seo писане на текст и въобще няма да я прочетат.
От трета – моя лична. Наистина чудесна статия за Seo текст. Не случайно си номер 1 при много търсения. Но много по-силен ефект от подобен линкбайт според мен би се получил от развиване на статията към начинаещите – тогава наистина ще има много линкове от форуми.
P.S. Не смея да коментирам задълбочено за заявките тъй като не съм добър в php/mysql, затова и съм си наел подходящите хора. -
Програмирането наистина не ми е чак толкова силна страна. Знам ги нещата, но бъркам понятията и е възможно да объркам някой. Присъщо е за мен да обяснявам нещата с мои думи с цел опростяване, но понякога се получава точно обратното.
Сега пиша една статия за защита от MySQL Injection и XSS, но ще я позабавя малко, за да може да е колкото се може по-добра и лесна за разбиране.
-
Да не забравиш да погледнеш моята версия за защита чрез htaccess, макар, че бях оплют от доста хора за нея, смея да твърдя, че ми вършила доста добра работа.
-
Интересно е и ще работи. По принцип е достатъчно да се филтрират само кавичките. Но ако някой наистина разбира от тези неща, няма да те оплюва, а ще ти каже, че това е една перфектна защита в дълбочина. А именно в това е майсторлъкът ;)
