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

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

Наскоро работих по сайта Речник на думите в българския език. В този сайт при търсене по някоя дума в дясната колона се зарежда блок с подобни думи. Подобните думи са такива, които се получават от търсената дума с добавяне, премахване или подмяна на една или две букви. За откриването на такива думи се използва алгоритъм с висока степен на сложност, който е бавен, защото претърсва цялата таблица с думи. Таблицата беше с размер около 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, или допълнителен блок с връзки като този със „Случайни думи“. Още по-добра работа би свършил блок със „Съседни думи“, в който за дадена страница връзките винаги да са едни и същи.

Прочетена:6849
« Предишна публикация

Бутони за социални мрежи v.2

Нова версия на скрипт за бутони за споделяне на ликове в сайтове за споделяне на връзки и социалните мрежи. Избрани са сайтове, които вършат добра работа при SEO оптимизация. Старата версия на скрипта е в статията ... Повече информация »

Следваща публикация »

Споделяне на достъп до Google Analytics и Google Adwords

Google Analytics Google Analytics е безплатен уеб инструмент на Гугъл за следене на броя на посещенията на твоя сайт, както и автоматично  извършване на анализ на трафика. Понякога се налага да дадеш достъп на външен човек ... Повече информация »

10 коментара

  1. Victor 16.03.2010
  2. Марто 16.03.2010
  3. gan 16.03.2010
  4. Марто 16.03.2010
  5. gan 16.03.2010
  6. Марто 16.03.2010
  7. gan 17.03.2010
  8. Марто 17.03.2010
  9. gan 17.03.2010
  10. Иван 20.08.2013