Joomla! България
Joomla! 3.x => Общи въпроси за Joomla! 3.x => Темата е започната от: sashomasho в 14 Февруари, 2017, 16:47:19
-
Какво е примливото време за отговор на съръвъра?
От какво зависи времето за отговор на съръвара?
Скоростния тест на гоогле препоръчва 200 мс
-
От какво зависи времето за отговор на съръвара?
От това какъв е, как е конфигуриран, колко се товари от уеб приложенията качени на него и тн...
-
Хардуера също е от значение.
-
Благодаря.
И към двамата
Мишо: Пример за конфигуриране.
Бого: Пример за хардуер
-
sashomasho, приемливо време за отговор на съръвъра е до 0.4-0.5 сек, а според гугъл - до 0.2 сек. Ако съървъра ти връща отговор за над 0.2 сек, Google Pagespeed insights (https://developers.google.com/speed/pagespeed/insights/) ще ти върне отговор че трябва да намалиш времето за отговор.
Зависи от много неща - коя система ползваш, дали си включил кеша, с колко неща е натрупана съответната страница която проверяваш, дали имаш бавни заявки към базата данни и изобщо колко са заявките - колкото повече, толкова повече ще се забави с отговора сървъра.
Тук във форума имаше един умник, който пишеше, че не трябвало да се включва кеша на ядрото на джумла. Без него, няма шанс дори и гола празна джумла да ти върне отговор за под 0.5 на споделен хостинг. С включен кеш, стига страницата да е кеширана, времето пада обикновено на 0.1-0.3 (за нова празна джумла).
Ако имаш впс сървър който е достатъчно мощен за сайтовете които си качил на него, 0.1-0.2 сек. е отлична стойност и няма голям смисъл да се гони по-ниска (освен ако не си Гугъл, Амазон или Ибей).
Може да се тества още и с:
https://gtmetrix.com/
http://www.webpagetest.org/
https://tools.pingdom.com/
Пример за хардуер:
- Джумла сайт с включен кеш с нормални размери от до 100-200 страници, който не е накичен с много допълнителни плъгини и модули, и е базиран на добър платен темплейт, работи чудесно на най-евтините планове на повечето БГ споделени хостинги.
- За Джумла сайт с включен кеш който има повече от 1000-2000 страници, аз бих ползвал ВПС. Ако си с изключен кеш при сайт с такива размери, ще ти се наложи да плащаш доста повече пари за хостинг - или да си на по-високите ценови нива споделен хост, или по-мощен ВПС.
-
Благодаря за информациятя
Това което намерих аз като допълнителна инфорамция е че реален тест за отговор на сървъра се прави със статичен елемент, дакажем малка снимка:
www.site.com/image.jpg
Това ти дава реална представа за отговор на сървъра защото не засягаш никакви пхп скриптове и т.н..
След като направиш този тест правиш тест и на сайта
Примерно време за отговор със снимка 0.2 сек, а сайт 0.9 секунди, значи забавянето от самия сайт е около 0.7 секунди...
Да разбира се кеширането е пуснато.
Спомням си че беше дал някъде настройки за .htaccess но нещо не ги намирам. Може би това ще ми повдигне малко параметрите.
По принцип ползвам ВПС
ако да кажем на него има сайтове с магазини с по 10 000 - 30 000 продукта
К2 с около 500 статии
добавени са приложения и т.н.
Какви трябва да са параметрите на съръвара който да обслужват подобно нещо така че да няма дразнещо бавене за потребителите когато посещават подобен сайт.
-
Много зависи и от посещаемостта на сайтовете, но ще ти трябва нещо около 2 GB памет (RAM) и 2 процесорни ядра на ВПС-а.
Настройки за .htaccess (те са за максимално бързодействие на сайта, не за минимален товар върху сървъра):
http://3dwebdesign.org/forum/htaccess-code-to-speed-up-joomla-t1058#entry8439
-
Благодаря за линка
То ВПСа е с 2 ГБ рам и 3 ядра. Но нещо ми се струва че недостига..
-
Значи трябва да си тестваш сайта за модули които товарят и като минимум да им включиш кеша. Най-товарещи са модулите които генерират случайни продукти (или случайни новини), а също така и модула най-посещавани - обхожда цялата таблица преди да върне отговора. По само една бройка от тези модули вкючени на заглавната ти страница, може да ти забавят сайта при всяко отваряне с по над секунда - в 90% от случаите заявките им са бавни.
Също така най-малкото което можеш да направиш е да си оптимизираш базата данни и да изтриеш от нея ненужните неща. Например да изпразниш таблиците на умното търсене и на компонента за редирект. Също така можеш и да изключиш плъгините на тези два компонента за да не продължават да ти пълнят базата. Тези два плъгина пълнят по 500 мб на година базите на някои сайтове.
-
Тук във форума имаше един умник, който пишеше, че не трябвало да се включва кеша на ядрото на джумла.
Това съм аз май, защо навремето, а пуснеш кеша и гръмне мартата. Сега не знам как е.
А иначе умното търсене - направо трябва да се реже.
-
Мишо, не си ти, дори да си го писал някога си, със сигурност не съм го прочел. Имам предвид преводача - бе го написал в "онази" тема наскоро.
-
To
Мишо, не си ти, дори да си го писал някога си
То беше отдавна, още при версия на VirtueMart 1.0 или 1.1 //не си спомням вече.
По-важното е сега да видят ползващите VM 3, дали се държи коректно при пуснат кеш от ядрото и дали завършва поръчката.
Жоре, ти си май най-стария тук, ползващ VirtueMart. Тествай дали работи с кеша, че аз нямам вече дори и тестова инсталация на Марта.
-
Кеш за магазин ...изобщо не е препоръчително! Ще има проблем с количката. ;)
-
Кеш ползвам от 1-2 години - като порастнаха сайтовете.
Виртуемарт няма никаъв проблем при кеширането за версия 3.х
Няма проблеми с колички модули и т.н.
По принцип всичко що може да кешира съм го пуснал.
спрях умното търсене и редиректите
Изпразних им таблиците
Ако има още нещо което да се спре и изчисти кажете...
Чета тук там че препоръчват използването на добавка която компресира джава скрипт и тн.
оправдано ли е това...
-
Кеш за магазин ...изобщо не е препоръчително! Ще има проблем с количката. ;)
Ако на голям магазин е включиш кеша просто умира.
-
Много зависи и от посещаемостта на сайтовете, но ще ти трябва нещо около 2 GB памет (RAM) и 2 процесорни ядра на ВПС-а.
Настройки за .htaccess (те са за максимално бързодействие на сайта, не за минимален товар върху сървъра):
http://3dwebdesign.org/forum/htaccess-code-to-speed-up-joomla-t1058#entry8439
Пробвам последната версия която днес си публикувал там но ми върща
500 Internal Server Error
Има ли нещо специфично.
Преди като съм ползвал тези настройки не ми е правило проблем.
Да не би да има някакви промени при 3.6.5
не разбирам от това хич
-
Виж си заявките, от там според мен ти издват проблемите.
-
Не е от кода - има си проверки за всеки модул дали работи на сървъра. Провери дали не ти е станал Htaccess файла на един ред. В Notepad++ : Редактиране-формат за край на реда-преобразуване в уиндоус формат.
-
Забавянето зареждането на сайта може да е от доста причини, но не изключвам заявките!
-
Не е от кода - има си проверки за всеки модул дали работи на сървъра. Провери дали не ти е станал Htaccess файла на един ред. В Notepad++ : Редактиране-формат за край на реда-преобразуване в уиндоус формат.
Тествах модулите един по един.
Оказва се че този прави проблем. Това е така защото имаш пренасяне на нов ред - втори и трети ред. Поправи си го във форума че може и други да се чудят какво става. След поправката ми пработи както трябва.
ht
m)$">
<IfModule mod_headers.c>
<FilesMatch "\.(ttf|otf|eot|woff|svg|ico|pdf|flv|swf|js|css|gif|png|jpg|jpeg|ico|txt|html|ht
m)$">
Header set Cache-Control "max-age=2592000, public"
</FilesMatch>
</IfModule>
Благодаря
-
Забавянето зареждането на сайта може да е от доста причини, но не изключвам заявките!
Може и от заявките да е, ама без заявки няма сайт...
Повечето неща се зареждат за секунди...
Ще изследвам по-пордорбно... но няма как да намаля заявките до 0 ;)
-
Сложи един html сайт и направи тестове да видим какво ще покаже. ;)
-
Подобрихме с 20 точки гоогле скоростта което основно мисля, че се дължи на .htaccess
Изписва да минимизирам JavaScript CSS
Е има ли смисъл да го намалям със 7 к едното а другото с 8 к
Не виждам друго да има скриптовете се зареждат за милисекунди.. евентуално остава бързодействието на сървъра.
Въпросът е
повече ядра
или
повече рам
-
За кой сайт става въпрос, за този в подписа ли ти?
edit/ 108 заявки в home page ...какво очакваш...
-
И за него и за други
-
Не ми става ясно защо, но всеки път го въвеждам правилно, а глупавия форум го пренася на нов ред... сигурно има проверка за определен брой символи без интервали - защита срещу спам... както и да е, поправих го, мерси.
-
Аз по принцип се чудя защо е във форум, а не в статия. По добро СЕО?
-
А иначе умното търсене - направо трябва да се реже.
Редиректа прави повече бели - пълни базата данни с огромни количества.
Аз по принцип се чудя защо е във форум, а не в статия. По добро СЕО?
Въпреки че и форума е стар, той засега е ок и ще може да работи още, а сайта трябва да се преработва всеки момент, затова и избягваме да постваме в него.
-
Много благодарим за линка с допълнението към .htaccess
А въпросният SmartSearch е невероятно полезен при търсене в сайт с много-много текстове с функцията му за сортиране на резултатите по релевантност и някои др. екстри при работа с резултатите. А не откривам аналози с основния Search. Ще съм много благодарен ако някой знае нещо повече по този въпрос. Щото и от хостингите помолват да го спираме SmartSearch :-)
-
@plam, Сортирането на резултатите по релевантност от умното търсене е всъщност извеждане най-отгоре на статията в която се съдържа най-много на брой пъти думата. Тоест, умното търсене просто подрежда резултатите по брой съвпадения.
За мен това не е релевантност. Това че в една статия се съдържа думата 20 пъти, едва ли я прави най-правилната за приоритетно показване на потребителя ;)
-
Така е, но стандартното търсене даже и това не прави... Подреждането на по-големия бр. срещания най-отгоре дава повече шанс търсения смисъл тук да е най-пълен. Или поне няколко блока по-долу, което интелекта на търсещия много по-лесно ще прецени, отколкото непредвидимата подредба в резултатите от стандартния сърч (или допълнителните му филтри в резултатите).
А и SmartSearch още в резултатите показва само точни части-контекст с маркирани резултати (стандартният тук е лотария) и при отваряне на статия – всички търсени термини също вече са маркирани в целия текст. Добре е замислен и много добра работа върши...
Остава само да има вариант как да може по-безболезнено и за сайта, и за хостинга да се ползва SmartSearch ? :)
-
Умното търсене до колкото знам е само ако ползваш вградения модул за търсене и всяко допълнително приложение посредством добавка дава възможност да се търси в него.
Аз обаче не виждам смисъл когато се търси в магазин да се намесват останали приложения и смятам че трябва да се ползва търсещия модул за самото приложение.
От друга страна умното търсене като ти излюе смесено информация от всякакви източници в сайта не знам как робота ще прецени кое най-подходящо за потребителя.
За мен умното търсене е ако може да търси по корена на думата образно казано.
Примерно пишеш БРАДВАР и ти извиква освен БРАДВА и БРАДВИЧКА освен БРАДВАР, а бих я нарекъл интелигентна ако ти изведе и резултати за СЕКИРА... и сниноними
-
... за магазин – да.
Имах предвид за сайт с огромно количество текстове (примерно издателство), където скромните възможности на стандартното търсене само донякъде вършат работа.
-
sashomasho ти говориш вече за АИ което няма как да стане без обучение на робота.
Да умно(уф) или интелигентно търсене изисква програмирана логика, което за съжаление в българският език, не знам да е направено за който и да е екстенжън. И тук говорим за мнооого голям проблем, имайки предвид двойното и тройно понякога значение на българските думи И словосъчетания.
Тук на помощ идват таговете и при реално добре организиран магазин с добре премислени тагове, търсачката би ограничила заявките до таговете, което предполагам ще ограничи и заявките в базата данни.
Едно е заявката да е селект фром където дума х е 5 пъти или 10 -това е безумие, но селект фром където тагс е = 1,2,3 драстично би съкратило така нареченото умно търсене.
По принцип идеята за таговете в модерните магазини е точно тази защото проблема не е от вчера.
Не знам дали ми следите мисълта, но като се абстрахираме от сървърните настройки, базата си е база и заявките също.
Има разбирасе значение, дали ползваш чист апаш или комбинация с NGINX, но заявката си е заявка и трябва да се процесира.
Ако търсачка е програмирана да търси по тагове и таговете са добре премислени, като ключови думи а и като спецификации на продукта, то заявките в базата би трябвало теоретично а и на практика да са много по-малко, а ако не са, то поне процесирането им да се изпълнява в пъти по-бързо.
Поправете ме ако греша.
-
@plam възможное и да е полезна, но не е това което трябва да бъде
@bongo1111 програмирането не е кой знае каква философия... синонимен речник + морфологичен разбор и да кажем 90% от работата е свършена.
Основият проблем според мен е че голяма част от приложенията, да не казвам всички се правят от програмисти които не се консултират със СЕО специалист, специалист по продажби, специалист по маркетинг и реклама ако говорим за магазин или пък със спциалист по недвижими имоти ако се прави приложение за този бранш. Те нямат и човек в екипа си който да има бегла представа. Оптимизацията и бързодействието пък не ги интересува защото не го правят за тях и го правят с тест за 50 или 100 продукта (всички демота са с малко количество инфорамция дали са статии или продукти). Още по лошо е когато кажеш на програмист основните грешки в приложението му и той откаже да ги промени развие. Срещал съм и такива които ги е грижа приложенията им да санат най-добрите и направо си просят предложения какво да добавят какво да модифицират че да стане по-добре.
Но да се върнем на търсенето...
При таговете... то пак си е търсене дали ще са тагове или ключови думи или заглавие количеството думи в тези полета горе долу е едно и също. Така че няма как да се спести време за обработка.
Ако ограничиш до 1-2 така (думи) свой продукт или статия ще пропуснеш да изведеш полезни за постетитея данни. Плюс това трябва да имаш предложения в реално време за ключовите думи когато започнеш да ги въвеждаш, което означава че ще имаш заявка и търсене при всяка нова написана буква.
Оптимизацията си има някакви граници. От там нататък вероятно решението е в по-мощна машина. Така като съм преминал от споделен хостин на ВПС така и ВПСа трябва да се осъвременява.
При 5 или 10 000 статии/продукта имаш огромно преравяне на информация при всяко търсене
При кеш за всяка търсена ключова дума пък трупаш голяма база. От друга страна този кеш се трие на определено време защото трябва да обхване новите статии/продукти. И става един порочен кръг...
И пак стигаме до по-добра машина която да обработва по-бързо заявките. Всеки казва намали си заявките. Мога да ги сведа до 1 (хтмл сайт) но се връщам 15 години назад.
Въпросът ми е каква трябва да е машината (рам, ядра) за да се почувства осезаемо подобрение...
В днешно време мисля че оказва влияние и ССД дисковете. Виждам огромна разлика в няколко работни станции на които обработвам огромни количества данни с ССД. Лошото е че в момента ССД сървърите са с цена 7 пъти по-висока от колкото ХДД.
-
Колко плащаш за сегашния впс ?
-
Разлика в бързодействието ще усетиш повече от повече памет и от SSD диск, процесора не е толкова ограничаващ фактор. За начало си вдигна рам паметта и следи какво ще се случи.
-
Има разбирасе значение, дали ползваш чист апаш или комбинация с NGINX, но заявката си е заявка и трябва да се процесира.
Това е много добро решение за разтоварване на apache-to и вдигането на производителността.
Ако статичното съдържание е изнесено на под домейн, който работи на nginx - резултата е в пъти по-добър, отколкото всичко да е на apache.
https://forum.joomla.bg/index.php?topic=746.0
https://docs.joomla.org/Nginx
-
Благодаря за информациятя
Това което намерих аз като допълнителна инфорамция е че реален тест за отговор на сървъра се прави със статичен елемент, дакажем малка снимка:
www.site.com/image.jpg
Здравей,
точно това ти казах още в началото/html страница/, гледам си махнал доста от нещата в началната страница, сега заявките са в пъти по-малко и съответно е скочила скоростта на сайта.
-
@Уеб дизайн Seo
Благодаря... Лошото е че все още ССД сървърите са скъпи но ще направя едно проучване за текущия пазар.
@ Михаил Михов обясни накратко за какво става дума, и евентуално без изнасяне на статично съдържание на поддомейн
@ Бого ако гледаш сайта в подписа ми то него не съм го променял от отдавна завяките са все същите. Може би кеш и настройките от Еди за кеширане в браузъра. Не знам как да намаля повече заявките
-
Да попитам какви трябва да са настройките на PHP сървъра да кажем от към:
memory_limit
и раздни други такива важни параметри... какви стойности препоръчвате
Има ли нещо общо РАМ паметта на сървъра която да кажем е 2048 МБ с memory_limit който се задава в ПХП конфигурацията....
-
Старият ли сървър е?
-
същият