Нов код за Referring Links? – търся съвет
Последният месец, моят инструмент за препращащи връзки Referring Links загуби голяма част от потребителите си. Причината е в хостинга – HostBulgaria изглежда имат огромни проблеми със сървъра DAO. Не само че инструментът започва да не отчита правилно, но се получава нещо друго, много по-неприятно – започва да бави зареждането на страниците на потребителите.
Разбирам всеки, който го е махнал. Дори мен самия ме дразни всичко това, но проблемът просто не зависи от мен. Знам какво бихте ме посъветвали – да сменя хостинга. Според мен това не е решение, защото сървърът рано или късно ще се оправи. Но трябва да намеря решение за случаите, когато сървъра го няма.
Много мислих, какви ли не гимнастики правих, но просто JavaScript е така проектиран, че трудно да се реагира на подобни проблеми. Затова мисля да прибегна към нещо, което силно се надявах да не правя – да променя кода за потребителите. Засега още го обмислям, но май натам вървят нещата. Естествено, старият код ще си работи.
Засега съм измислил това:
<script type="text/javascript">
var links = 7;
var banned = "example.com,someword";
var language = "bg";
document.write(unescape("%3Cscript src='http://referringlinks.com/script.js' type='text/javascript'%3E%3C/script%3E"));
</script>
Искам съвет от хората, които повечко разбират от програмиране – това правилно решение ли е? Обяснявам: След приемането на необходимите за скрипта параметри, чрез функцията write генерираме ново извикване на скрипт на следващо ниво. Когато сайта се зарежда, той изисква първо ниво.
То винаги се зарежда, защото не зависи от външния сайт (сайта на скрипта). Така следващото ниво се зарежда след зареждането на сайта или по-точно не зависи от зареждането на сайта и не го бави. На този блог в момента върви този експериментален код и дава доста добри резултати. Скрипта си хваща стиловете и си отчита.
Кодът си остава валиден спрямо W3C, JavaScript конзолата не дава никакви грешки. Ако сървърът липсва, просто нищо не се появява, като отново грешки не се генерират, нито се забава зареждането на сайта. Както казах, това е най-големият и досаден проблем в старата версия на кода.
Много сложно го обясних май, но той целият скрипт е една голяма сложнотия. Постоянно се появяват нови проблеми и предизвикателства. Мечтая си да го изкарам от Beta, но няма да е в следващите 3 месеца. Въпреки всичко съм оптимист за бъдещето на инструмента. Смятам, че ще го довърша все някога :)
Забележете, че има параметър за български език (bg). Скоро не само widget-а, но и сайта ще има и българска версия.
бутон за споделяне в социални мрежи
Коментари
15 коментара за Нов код за Referring Links? – търся съвет
-
Марто на 13.04.2009 18:38
Този вариант не ти решава проблема. JavaScript-а първо се изпълнява и след това продължава да рендва/зарежда останалата част от страницата.
Тоест както е сега пак ще бави зареждането на страниците.За да стане както трябва е необходимо да зареждаш скрипта след като основното дом дърво е цяло (тоест когато се е заредил HTML).
Преди известно време писах подобен скрипт за st.notrial.info и гарантирано работи перфектно. -
Засега имам чувството, че се държи добре, но ще изчакам DAO сървъра да падне, за да го докажа.
Искаш да кажеш, да изпълнявам скрипта, след като цялата страница се зареди? „window.onload = start_function“
Ще помисля над това, но все имам чувството, че забавянето на сайта идва от връзката със скрипта, а не от неговото изпълнение.
Все-пак самия JavaScript е относително прост, за да товари.
-
Всъщност сега погледнах как си реализираш тракването. Още от проектирането му си заложил грешна стратегия – колкото повече посетители минават през него толкова по-голям е процента неотчетени. Пропуснал си момента, че файла „script.js“ се кешира и това води до неотчитане, тъй като браузера не прави заявка към сървъра:)
-
Файлът не се кешира, повярвай ми. Погледни HTTP хедърите. Тъй като JavaScript-а се генерира от PHP, самото PHP връща хедър Cache-Control: no-cache . А и нали сравнявам с други статистики.
Това с извикването на края няма да стане. Сега се сетих, че съм го пробвал още в началото. Потребителският сайт изчезва и се показва само резултата от скрипта.
Сега гледам новия код на Google Analytics – решили са си проблема като мен :) Даже използват абсолютно същия метод с функцията unescape. Май това е начина.
-
не виждам логика, защо с unescape да работи?
-
Прави сте, отново не работи както трябва. Тоест, отново се лагва, като падне сървърът. Преди малко падна и сам се убедих. Може да пробвам поне да го сложа в try-catch, но едва ли ще помогне.
При всяко положение има решение, защото рекламите на Google Adsense се зареждат по този начин, а те не могат да си позволят да лагват сайта. Изглежда @Марто е прав и решението е в изпълнение на скрипта след зареждане на страницата.
Но преди правих подобни експерименти и резултатът беше фатален. Освен пак да се позанимавам и да погледна как го правят Google Adsense.
-
Честно казано, учудвам се, че си сложил подобна система на shared хостинг (вероятно още само я тестваш как се държи?). Най-нормалното нещо е подобни сървъри да се „сгънат“ под натоварването от десетките сайтове качени на тях – било то заради голям трафик или бъгави скриптове. За съжаление (но не и за учудване) hostbulgaria не правят изключение и като гледам как се развиват нещата – по-лошо ще става.
Единственото добро решение е dedicated сървър, но това е свързано с повече разходи (които все пак може би ще се оправдаят, когато referringlinks.com се развие и генерира приходи). -
Най-много усилия съм съсредоточил в оптимизацията и защитата на системата. Освен нея, на хостинг акаунта ми има още 3-4 сайта, които също товарят. Според последните статистики, обаче, изразходвам само 12, от позволените ми 20 CPU минути на ден.
Така че сървъра не се претоварва и това да бави зареждането. Проблемът е самата реализация и това, че сървърът понякога липсва :)
-
Явно не си ме разбрал щом получаваш бяла страница. Малко е бавна комуникацията тук – пиши ми на icq 178489938
-
@Васил Тошков
Честно казано, нямам идея какво точно отчитат като CPU минути (само apache?), а и CPU не е единствения ресурс…
Със DAO и CHI сървърите се е случвало да ми каже:
mysql_connect() [function.mysql-connect]: User xxx already has more than ‘max_user_connections’ active connections.
и то за сайт, който я има 5 посетителя дневно, я не.
Отделно се е получавало така, че PHP е изяло отделената му памет и при опит за някаква операция, която изисква заделяне на памет (примерно отваряне на картинка с GD) ми казва нещо от сорта:
Failed to allocate 6238 bytes (Totally used 68M). -
И на мен ми се случва често с max_user_connections и честно казано не е приятно. Затова за всеки сайт и по-сериозен скрипт правя отделен mysql потребител. Но и това имам чувството, че не помага.
-
За да избегнеш забавянето заради жабата пиши с нея един iframe с необходимите параметри в урл, или картинка
-
В крайна сметка единственото решение със забавянето е стабилен сървър. Както каза Dzver, този новия код е абсолютно идентичен със стария, затова че стария код си остава. Едва ли някога ще се промени.
Сложих си гаджет за микроблог на Twitter и в сравнение с ReferringLinks е 5 пъти по-бавен. Това ме успокоява, че забавянето не зависи от мен. В случая се дължи главно на отдалечените от България сървъри.
@Асен – iframe не е според стандартите и пречи инструментът да се интегрира с дизайна на потребителския сайт. Просто ще се надявам браузърите на бъдещето да решат този проблем с JavaScript, ако това е възможно.
Повечето gadget-и са на този принцип и нещата не могат да останат така.
-
Аз оставам верен на идеята :) Не съм го махал и нямам намерение. Сложих новият код да видим, какъв ще е резултата.
-
@Стойчев – Много ти благодаря, че си потребител на системата! Точно в момента имам нужда от потребители – на 7-ми Юли ще ми е представянето на дипломната и завършваааам.
Само имам една малка забележка – този код горе няма нищо в повече от стария, така че по-добре си използвай стария. Оказа се, че съм бил в голяма заблуда, но така е, всеки се учи.
С две думи – този код горе си работи, но препоръчвам на всички да си използват стандартния. Не се знае в бъдеще какво ще се промени. Исках да го оптимизирам, но се оказа, че от стария код по-оптимизирано нема.
Системата иначе е готова откъм функционалност, остава само някой ден до края на месеца да си надвия мързела и да преведа една българска версия. Иначе откъм програмиране достигна съвършенството според мен.
