SEO блог и уеб програмиране » съвет

Зареждане на данни с Ajax от отдалечен сървър

Георги Стефанов — Mon, 15 Mar 2010 09:48:49 +0000

Задача за оптимизиране бързината на сайт

Наскоро работих по сайта Речник на думите в българския език. В този сайт при търсене по някоя дума в дясната колона се зарежда блок с подобни думи. Подобните думи са такива, които се получават от търсената дума с добавяне, премахване или подмяна на една или две букви. За откриването на такива думи се използва алгоритъм с висока степен на сложност, който е бавен, защото претърсва цялата таблица с думи. Таблицата беше с размер около 100 000 реда и нарастваше и в резултат на това зареждането на страницата се бавеше до към 30 секунди – прекалено дълго време за уеб страница. Задачата ми беше да измисля начин за оптимизиране на бързодействието на сайта.

Решение

Първото, което направих е да опитам да оптимизирам SQL заявката. Ползваният алгоритъм не подлежи на оптимизация, затова се наложи да прибягна до някои дребни хитрости. Например търсене на подобни думи в ограничен набор от думи с дължина +/-2 спрямо дължината на търсената дума. Създадох някои допълнителни индекси на SQL таблиците и успях да съкратя средното време на около 8 секунди. Да чакаш цялата страница 8 секунди също е прекалено досадно и затова направих блока с подобни думи да се зарежда с Ajax. По този начин страницата се показваше веднага и само блока се бавеше, което беше напълно допустимо. Вече си мислех, че съм приключил, когато дойде писмо от хостинг доставчика, че се ползва прекалено бавна заявка, която бави другите сайтове на този споделен хостинг и настояваха да се оптимизира. Така стигнах до идеята, че данните за подобните думи трябва да се зареждат от отдалечен сървър. За да стане възможно това, трябва отдалеченият сървър да има същата таблица с думи в базата си данни. Направих автоматичен скрипт, който периодично да копира таблиците от единия сървър на другия. По този начин освен всичко друго се получи и още един архив на данните. След това оставаше да направя Ajax да се обръща към новия сървър. Тук отново има проблем: от съображения за сигурност Ajax не може да се обръща към домейн различен от този, на който се изпълнява. За да заобиколя това ограничение аз използвам следната програмистка техника: Ajax се обръща към скрипта similarClient.php разположен локално на сървъра на rechnik.info, който прави заявка към скрипт с име words.php на отдалечения сървър. Там се търси за подобни думи в копието на базата данни и намерения резултат се изпраща към similarClient.php, който го връща като резултат към Ajax. Към цялата система се добавя и кеширане на заявките, локално върху отдалечения сървър – този подход спестява дисково пространство на хостинга за сметка на увеличен трафик. При първото търсене в речника по дадена дума резултата се бави няколко секунди, но при всяко следващо търсене по тази дума, резултата се взема от кеш и става почти моментално. Всичко това може да изглежда малко сложно, но можеш да видиш колко добре действа в сайта на Речника.

Сигурност

Скриптът разположен на отдалечения сървър, който получава дума и връща списък с подобни думи е уеб скрипт и се извиква през HTTP. Това означава, че всеки който знае URL адреса и какви параметри приема, може лесно да използва това за свои цели и да прави заявки към сървъра. Използвайки горния метод, аз скривам URL адреса и това повишава сигурността многократно. Въпреки това е възможно връзката да бъде подслушана или логовете на сървъра да станат достъпни публично. Това ще разкрие URL адреса и някой може да се възползва. Затова един съвет: никога не разчитай само на сложен и таен URL адрес на скрипт!

Аз използвам допълнителни механизми за защита: отдалеченият сървър приема заявки само от IP адреса на rechnik.info. Това увеличава сигурността, но за съжаление не е напълно достатъчно, защото е възможно да пристигнат заявки с фалшифициран IP адрес. Следващиата стъпка е добавяне на кодиран параметър в GET заявката. По този начин URL адреса на заявката прилича на следния:

http://remote.domain.com/words.php?a=дума&code=a4b25d814f32b2c852c3d71d3

Низа подаван в променливата „code“, е кодирана от скрипта similarClient.php и само скрипта words.php знае как да го разкодира и да разбере дали е валиден. Резултат се връща, само ако стойността е валидна, в противен случай опита се записва и се съобщава на админ. За да може някой да хакне това, трябва да има FTP достъп до някой от двата php файла.Следващата стъпка е ползване на HTTPS вместо HTTP, но тук вече навлизаме в сферата на банковия софтуер

Сигурен съм, че много хора ще се запитат: „За какво е всичко това? Какво толкова защитаваш?“.

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

SEO

Описаната система си има и недостатъци. От SEO гледна точка връзките в блока Подобни думи са невидими за търсачките. За да може сайта да се индексира добре е нужен или Google sitemap, или допълнителен блок с връзки като този със „Случайни думи“. Още по-добра работа би свършил блок със „Съседни думи“, в който за дадена страница връзките винаги да са едни и същи.

Брой разглеждания на тази статия: 3332

Подобни статии:

Оптимизиране на бързодействието на сайт Пиша тази статия като продължение на статията PHP парсване на...
Оптимизиране на SQL заявки Основни положения при оптимизация на mySQL Обикновено проблемите с бавни...

PHP strlen() и текстове на кирилица

Георги Стефанов — Wed, 23 Dec 2009 18:27:14 +0000

Проблем

Вече в няколко сайта уеб директории, забелязвам следния проблем: в уеб формата за качване на сайт полетата имат ограничение в броя на символите, което е нормално, но е проблем, когато пише, че може да въведеш 100 символа, а реално можеш да въведеш само 50. Още по-досадно и времеотнемащо е, ако софтуера създаващ уеб формата не се грижи да запомни всички въведени полета и при грешка в едно от полетата изтрива всички полета – за форми с много полета това е направо кошмар, защото трябва да въвеждаш всичко отначало.

Най-фрапиращ случай за това е сайта bestbgsites.com. Не е лесно да добавиш линк в този сайт. Гърми грешката: „Името на сайта е прекалено дълго! Може да бъде 85 символа“ проблема е, че ако заглавието е на кирилица дължината е до 42 символа Описанието пише, че може да бъде до 255 символа, но реално са 127. Има и кратко описание до 30 символа (реално 15), което е трудно за измисляне. Ако сбъркаш някое от полетата всичките въведени данни се изтриват и трябва да се попълват повторно

Същия проблем има и сайта bglogs.com, като тук формата запомня полетата, но пък има ограничение в броя на грешните опити, след което пак трябва да започнеш на чисто. Полетата Описание и META Description пише, че имат лимит 500 символа и дори има Javascript, който намалява брояча на символите при всяко натискане на клавиш, когато въвеждаш в полето. Проблемът идва, когато изпратиш данните към сървъра, той ги проверява и ти показва, че си превишил доста лимита. В полето Заглавие е още по-трудно, защото лимита е замислен да бъде 100 символа, но на кирилица са само 50.

Обяснение

Тези проблеми се получават, защото представянето на всеки символ на кирилица при UTF8 е в 2 байта. Сайтовете ползват готов безплатен софтуер писан от англо-говорящи, които са свикнали при проверка държина на низ да използват PHP функцията strlen(), която работи на ниво байтове и затова тази функция преброява низ на кирилица с дължина 50 символа, като низ с дължина 100 символа.

Решение

Решението е много лесно, но трябва да бъде извършено от собственика на сайта. Трябва функцията strlen() да се замени с функцията mb_strlen(), която се съобразява с енкодинга и правилно преброява низ независимо на какъв език е написан. Тази функция се осигурява от библиотеката mbstring (Multibyte String), която за щастие отдавна се поддържа от всички български хостинг доставчици.

Отрязване на низ на кирилица

Подобен проблем се получава, ако отрязваш низ на кирилица в енкодинг UTF8 например показване на извадка от новина. Ако искаш да покажеш първите 200 символа от новина и направиш

$text = substr($text, 0, 200);

като резултат ще имаш първите 100 символа, като е възможно последния символ да бъде „срязан по средата“, в смисъл, че от двата байта, с които е представен ще остане само първия и в резултат на това в страницата ще бъде показан странен символ, който е невалиден UTF8 символ и чупи страницата. В резултат на това страницата няма да може да бъде валидирана, като XHTML документ. Нямам лични наблюдения как се отразява това на SEO, но предполагам, че е проблем за ботовете на много от търсачките.

За да решиш този проблем трябва просто да замениш функцията substr() с функцията mb_substr(), като разбира се библиотеката mbstring трябва да е предварително инсталирана.

Заключение

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

Брой разглеждания на тази статия: 3695

Подобни статии:

Оптимизиране на бързодействието на сайт Пиша тази статия като продължение на статията PHP парсване на...

Оптимизиране на бързодействието на сайт

gan — Wed, 16 Dec 2009 10:17:24 +0000

Пиша тази статия като продължение на статията PHP парсване на XML новини за твоя сайт. Разглеждам оптимизиране на бързодействието на динамичен сайт, който зарежда информация от база данни.

Сайтът ganbox.com е разделен на две части, които се различават и визуално. Основен сайт за SEO оптимизация и SEO блог. Реших в лявата колона на основния сайт под менюто, да извеждам последните X на брой статии от блога. Вече имах готов код за извличане на новини от RSS хранилка, но си поставих и две допълнителни условия: бързодействие и сигурност при зареждане на страницата.

Бързодействие при зареждане на страница

Колкото и да е голям по обем твоя сайт, зареждането на началната страница трябва да бъде максимално бързо. Това се постига, чрез цялостно или частично кеширане на страницата. Бързодействието е важно основно по две причини:

1. Посетителите бързо ще загубят доверие в сайта, ако той редовно се зарежда бавно. Повечето ще се подразнят и ще спрат да го посещават и ще потърсят друг подобен сайт.

2. Поради SEO причини. Роботите на търсачките имат зададено време на изчакване за зареждане на страницата, която индексират. Ако страницата е прекалено бавна, тя няма да се индексира изобщо или ще се индексира частично. В резултат на това сайтът започва да се класира лошо по все повече ключови думи за търсене.

Сигурност при зареждане на страница

Тук под термина сигурност имам предвид, че началната страница е особено критична и трябва да се зареди на всяка цена. Щом уеб сървърът работи, страницата трябва да се зареди, дори и ако SQL сървъра е претоварен или недостъпен. Глупаво е да падне началната страница на твоя бизнес сайт, защото имало проблем с базата данни. При сайтове на споделен хостинг често много сайтове ползват един SQL сървър. Например към момента superhosting не ползват специален софтуер за виртуализация и ако един сайт претовари базата данни, много други сайтове, които нямат вина ще пострадат. Към момента те си решават този проблем с денонощно наблюдение.

Решаването на проблема с отпадане на базата данни се постига, като блокове от началната страница, в които се зарежда информация от базата данни или информация от друг сайт, се обработват по специален начин. Има два подхода или да се използва кеширане на тези блокове или да се ограничи времето за изчакване на всеки блок и ако няма резултат този блок просто не се зарежда. В примера от тази статия аз използвам комбиниран подход. Само ще спомена, че има вариант, при който може да се кешира цялата страница, но той не е толкова гъвкав, защото различни блокове може да е необходимо да се опресняват през различни интервали от време в зависимост от информацията, която съдържат. Например блок с новини извличани от друг сайт ще искаш да се опресняват през 5 мин., защото каква е ползата да съобщиш за заметресение часове след като се е случило. Докато блок със статии от блога, в който пишеш веднъж седмично е достатъчно да се опреснява веднъж на 12 часа. Има и още един вариант – блоковете да се зареждат с ajax, но това не е добре от SEO гледна точка.

Кеширане на съдържанието

Добре, стига приказки! Давай кода! Посочения код изисква PHP >=5 заради DOMDocument и curl модул, като и двете се предлагат стандартно от повечето хостинг доставчици.

# извличане на последните статии от блога
$rssArticleLimit = 2; # колко новини се показват
$cacheTime = 7200; # опресняване през 2 часа (в секунди 7200)
$rssCacheFilePath = 'blognews.html'; # път до кеш файла
$urlBlogRSS = 'http://feeds.feedburner.com/ganbox'; # url на RSS новини

# следните две се ползват за проверка дали са извлечени всички данни
$rssMinLen = 200; # минимален брой символи във кеш файла
$rssLastTag = '

'; # кеш файла завършва с този таг

# създаване или опресняване на кеш файла
if(!file_exists($rssCacheFilePath) # ако файлът все още не е създаден
|| filemtime($rssCacheFilePath) + $cacheTime < time() # или е променен преди повече от 2 часа
){
$xml = get_page_content($urlBlogRSS, 8, 14); /* само 8 сек. време за свързване и 14 сек. общо време за изпълнение, увеличи ако трябва */
if(!empty($xml)){
$htmlData = '';
/* от XML в масив */
$doc = new DOMDocument();
if($doc->loadXML($xml)){
$arrFeeds = array();
foreach ($doc->getElementsByTagName('item') as $node) {
$itemRSS = array (
'title' => $node->getElementsByTagName('title')->item(0)->nodeValue,
'desc' => $node->getElementsByTagName('description')->item(0)->nodeValue,
'link' => $node->getElementsByTagName('link')->item(0)->nodeValue,
'date' => $node->getElementsByTagName('pubDate')->item(0)->nodeValue,
);
array_push($arrFeeds, $itemRSS);
}
/* от масив в HTML */
$rssTitle = (1 == $rssArticleLimit) ? 'Последна статия' : "Последните $rssArticleLimit статии от блога";
$htmlData .= "

$rssTitle

";
$feedCount=0;
foreach($arrFeeds as $oneItem){
/* при мен базата има кодиране utf-8, а началната страница cp1251 следващия ред вероятно няма да ти трябва */
foreach($oneItem as $key=>$value){ $oneItem[$key]=iconv('utf-8','cp1251',$value); }
$feedCount++;
$htmlData .= '

.$oneItem['link'].'" class="feedLink">'.$oneItem['title'].'

';
$htmlData .= '

'.my_chunk_split($oneItem['desc']).'

';
$htmlData .= $rssLastTag;
if($rssArticleLimit>0 && $feedCount>=$rssArticleLimit) break;
}
}else{
/* това което е върнал сървъра не е XML и вероятно е някаква грешка изпрати си имейл с този $xml */
$mail_text = 'FILE'.__FILE__."\nLINE:".__LINE__."\nERROR: това което върна RSS сървъра не прилича на XML\nXML:$xml\n";
SendEmail($mail_text);
}
if(!empty($htmlData)){ /* ако са извлечени данни успешно */
if(strlen($htmlData) > $rssMinLen && preg_match('|'.$rssLastTag.'$|', $htmlData)){ /* още една проверка дали са извлечени всички данни */
$fh = @fopen($rssCacheFilePath, 'w'); /* презаписва файл */
if($fh){
@fwrite($fh, $htmlData);
@fclose($fh);
}else{ /* имейл до теб, че има проблем с писане в кеш файла */
$mail_text = 'FILE'.__FILE__."\nLINE:".__LINE__."\nERROR: проблем с писане в кеш файла $rssCacheFilePath\n";
SendEmail($mail_text);
}
}
}
}else{ /* времето за изчакване на RSS сървъра да върне отговор е изтекло */
$mail_text = 'FILE'.__FILE__."\nLINE:".__LINE__."\nERROR: времето за изчакване на RSS е изтекло\nXML:$xml\n";
SendEmail($mail_text);
}
}
/* показване на кеш файла, ако съдържа нещо */
if(file_exists($rssCacheFilePath)) {
$htmlData = file_get_contents($rssCacheFilePath);
if(strlen($htmlData) > $rssMinLen && preg_match('|'.$rssLastTag.'$|', $htmlData)){ /* проверка дали са извлечени всички данни */
print $htmlData;
}else{ /* едва ли ще се случи но за всеки случай си изпрати имейл, че кеш файла е непълен */
$mail_text = 'FILE'.__FILE__."\nLINE:".__LINE__."\nERROR: непълен кеш файл $rssCacheFilePath чупи началната страница\nHTML: $htmlData\n";
SendEmail($mail_text);
}
}

Обяснения на кода

При първото зареждане на страницата от посетител се извличат данните от RSS, преобразуват се в HTML и се записват във файл. При всяко следващо зареждане се проверява възрастта на кеш файла, ако е пресен се взема съдържанието му е се отпечатва светкавично в блока. Всичко останало от страницата, което няма нещо общо с база данни, се генерира от PHP. Ако файлът е остарял се прави опит да се извлекат данни от RSS, като се изчаква само няколко секунди. Ако времето е недостатъчно или в момента няма връзка с базата данни, администратора на сайта ще получи имейл и данните ще се заредят от кеш файла. Това ще забави зареждането на страницата само няколко секунди. Администраторът ще трябва да увеличи времето за изчакване, иначе ще получава периодично писма. В този пример са дадени стойности 8 и 14 сек. По този начин имаме само две положения: страницата се зарежда моментално или страницата се бави няколко секунди, след което се зарежда, като съдържанието на блока е от кеша и се уведомява администратора, че има проблем. Посочения метод има само един недостатък – след като пуснеш статия тя ще се появи със закъснение в началната страница. Това закъснение в примера е от 0 до 2 часа. Ако пишеш често, например по няколко статии на ден, може да намалиш времето на $cacheTime=1800; # половин час.

Използвани функции

get_page_content($url) – извлича съдържанието на страница като ползва curl библиотека, ако зададеното време изтече без да има резултат скрипта продължава.
Кодът на функцията е даден в статията PHP: Извличане текст от интернет страница.

my_chunk_split($str) – Ако текста съдържа дълги низове ги пренася на следващия ред при достигане на width последователни знака. При мен лявата колона е тясна и ако текста съдържа низ с повече от 28 знака един до друг без интервал, това кара текста да излезе от лявата колона и да навлезе в средната бяла колона.

function my_chunk_split($str, $width=28) {
$stmp = base64_encode($str);
$len = strlen($stmp);
$out = "";
$done=0;
while( $done<$len ) {
$out.=($len-$done>$width) ? substr($str, $done, $width). "\n"
: substr($str, $done, $len-$done). "\n";
$done+=$width;
}
return $out;
}

SendEmail($text) – изпраща text до администратора на сайта. Всеки може да си напише или да ползва библиотека (или просто да постъпи небрежно и да коментира тази функция в кода), затова няма да дам кода на функцията тук.

Ако твоя сайт се зарежда бавно и искаш оптимизиране на бързодействието може да се свържеш с мен за оферта от тук.

При проблеми с този код пиши коментари по статията.
.
.
Подобни статии:
PHP парсване на XML новини за твоя сайт
PHP: Извличане текст от интернет страница

Брой разглеждания на тази статия: 3936
(след дата 20 декември 2009)

Подобни статии:

Оптимизиране на SQL заявки Основни положения при оптимизация на mySQL Обикновено проблемите с бавни...
PHP парсване на XML новини за твоя сайт Ще ти покажа малко PHP код, с който много лесно...
Зареждане на данни с Ajax от отдалечен сървър Задача за оптимизиране бързината на сайт Наскоро работих по сайта...

Бъг в WordPress: визуалния редактор не работи

gan — Mon, 12 Oct 2009 17:11:23 +0000

Преди малко открих бъг в WordPress 2.8.4 (последната версия в момента).

Грешка

Докато за пореден път актуализирах любимата си статия Популяризиране на сайт с външни връзки, открих следния неприятен ефект – в админ панела при промяна на публикация визуалния редактор спира да зарежда текста и в долния десен ъгъл изчезна грапавото ъгълче за разтягане на полето с текста на публикацията. Така единствено в режим на HTML може да се промени статията.

Проучване

Разгледах внимателно цялата страница и забелязах, че страницата не се е заредила до края и не показва предишните версии на публикацията. В долния край на страницата има списък с предишни версии на публикацията, които се увеличават при всяка промяна на статията. Веднага след заглавието на списъка „Версии на публикацията“ страницата завършваше. Разгледах други публикации от блога, но там нямаше проблем. Това ме наведе на мисълта, че грешката се дължи на големия брой версии на публикацията и дългия текст. За съжаление в момента нямам време да прегледам кода на WordPress, но вероятно всички предишни версии се зареждат в паметта и при голям брой версии страницата се чупи.

Отворих cpanel на хостинга и от там влязох в phpMyAdmin. След кратко разглеждане на таблицата с публикациите wp_posts разбрах как да изведа броя на предишния брой публикации.От адреса на страницата за промяна на публикация се вижда, че номера на публикацията е 125. Адреса е: http://ganbox.com/blog/wp-admin/post.php?action=edit&post=125

Изпълнява се следната SQL заявка:

SELECT * FROM `wp_posts` WHERE `post_name` LIKE '125-%'

Където 125 е номера на публикацията и при мен изведе
Showing rows 0 – 29 (82 total, Query took 0.0041 sec)

Вижда се, че има 82 версии на публикацията, като се добави и това, че текста е дълъг бях сигурен, че това е проблема.

За всеки случай си направих резервно копие на таблицата wp_posts и след това реших да поизтрия малко стари версии.

Решение

Първо изпълних заявката

SELECT * FROM `wp_posts` WHERE `post_name` LIKE '125-%'
AND post_date < NOW() - INTERVAL 1 MONTH
ORDER BY post_date

Showing rows 0 – 29 (56 total, Query took 0.0173 sec)

Това ми показва, че има 56 версии по-стари от един месец.

Изтрих ги със заявката:

DELETE FROM `wp_posts` WHERE `post_name` LIKE '125-%'
AND post_date < NOW() - INTERVAL 1 MONTH

Всичко си заработи нормално при промяна на публикацията.

Явно този бъг се проявява много рядко и само, когато сумарния текст от всички версии на една публикация е прекалено голям. Ако и при теб „Визуалния редактор“ на WordPress спре да зарежда текста може да пробваш този хак.

Винаги прави резервни копия на базата данни преди да го използваш, ganbox.com не носи отговорност за проблеми възникнали от използването на този хак.

Брой разглеждания на тази статия: 3067
(след дата 20 декември 2009)

Подобни статии:

WordPress 2.9 на български Както сигурно вече си видял днес излезе новата версия на...