DerkonBG
Active Member
не беше ли архитект?
По професия съм systems architect. Не съм твърдял, че съм програмист. Даже няколко пъти споменах, че не съм.
Как да си намирате лийдове с ИИ? :)
- Автор metaverse
- Начална дата
MegaKaloyan
Well-Known Member
абе ти пък ... половината думички които ползва са ми непознати и се опитва да ни впечатли в някакъв марсианскометаверски език ... най ми е смешно като почне да ни обяснява колко сме невежи и неуки и не разбираме метаверския му език дето пише.... той да вземе да научи Български език , че е мега-турбо-супер смешен вече ако смята, че някой впечатлява с разните му дефиниции дето ги упоменава.Твоя сайт всеки може да си го тества
не беше ли архитект?
DevOps, SRE, SA, SE всичките сме glorified sysadmin.
DerkonBG
Active Member
Нещо не ти е наред щом говориш за себе си в множествено число!
MegaKaloyan
Well-Known Member
Sky
Well-Known Member
Е ти какво очакваш от един хтмл?
няма едно изображение даже
Sky
Well-Known Member
Скоростта на зареждане е най-малкия проблем на това нещо
Каква разлика очакваш ако има изображения? Blur placeholder или GPU транзишън, всичките му формати за различни устройства и с подходящи хедъри за кеширане от CDN-а и клиента? Lighthouse няма да се оплаче ако спазиш добрите практики. 2025г. сме.
Иначе добре. И без това се каня да сложа нещо ама искам да е интерактивно с threejs или някой емулатор. Просто не мога да реша какво да показва. Отворен съм към идеи.
Мога даже Doom 1 или Windows 98 с Heroes 3 да ти подкарам и пак ще е 95+ ама няма да пасне на темата
.Edit: хрумна ми нещо бързо за не е "един хтмл"
.
Последно редактирано:
DeathShuttle
Active Member
Според мен @DerkonBG се ебава с вас защото въпросния сайт от линка който е дал зарежда за под 300ms, на всички десетина страници които тествах а за търсачката нямам думи - безобразно бърза. И сайта хич не е на WP ами си е чисто къстъм решение; с wp такива резултати не се постигат.
p.s. това че @DerkonBG те “поряза” в по предни постове не е причина да не му харесваш сайта
Според мен @DerkonBG се ебава с вас защото въпросния сайт от линка който е дал зарежда за под 300ms, на всички десетина страници които тествах а за търсачката нямам думи - безобразно бърза. И сайта хич не е на WP ами си е чисто къстъм решение; с wp такива резултати не се постигат.
p.s. това че @DerkonBG те “поряза” в по предни постове не е причина да не му харесваш сайта
Websocket за сърч.
Върна ме 20г. назад.
DeathShuttle
Active Member
Ти явно си останал 20г. назад, това е най-бързия възможен вариант! Изключително добро пооадение! Но ако роптаеш че не можеш да му наспамиш търсачката ще те разбераWebsocket за сърч.
Допитай се до твоя ИИ и после пак коментирай вебсокета.Ти явно си останал 20г. назад, това е най-бързия възможен вариант! Изключително добро пооадение! Но ако роптаеш че не можеш да му наспамиш търсачката ще те разбера
Специално за търсене далеч не е най-бързия, но няма да споря. Тъй да бъде.
DeathShuttle
Active Member
Не спори, направи малко сметки колко ms се губят за всяко презареждане на страница и колко ms трябват за изпращане на 100 байта (търсения стринг) през вебсокета който е с вече установена конекция.
Предполагам че всички девелопъри на сайтове за борси са глупави и за това ползват вебсокет вместо ajax или пази боже орезареждане на страница.
Хайде жив и здрав и успех с WP-то, страхотно е, но за неможещите и мързеливите!
@Sky специално за теб си поиграх. Има доста easter eggs ако искаш мога да кръстя звезда на "Sky" ?
Не ми се занимава повече за днес. По-натам пак. Искам да показва в реално време енричмънт на някой от по-бавните сървиси и да оправя, когато градовете ходят на заден план да ги крие. Също и репорта в Lighthouse.
Надявам се е ок javascript, а не изображения или видео?
Не ми се занимава повече за днес. По-натам пак. Искам да показва в реално време енричмънт на някой от по-бавните сървиси и да оправя, когато градовете ходят на заден план да ги крие. Също и репорта в Lighthouse.
Надявам се е ок javascript, а не изображения или видео?
Последно редактирано:
DerkonBG
Active Member
В абсолютна заблуда си, това е най-бързия възможен вариант за търсене! Говоря да е удобно и бързо за потребителя а не разни ботове и скрапери да помпят търсачката!
@DeathShuttle вече се опита да ти покаже схема на тайминга, но явно имаш нужда от повече четене или повече разговори с ИИ
Веднъж установена конекцията, разхода на трафик е САМО за предаване на търсения стринг, както вече ти казаха 100-200 БАЙТА!!!!! Няма загуба (на ТРАФИК и CPU) за ajax call, изграждане на https конекцията и т.н.;
След това идва момента на връщането на резултата: на вебсокета връща само json или готов html, а на твоя вариант имаш ПЪЛНО
предаване на html, CSS, javascript зарежданки и т.н.!
@DeathShuttle , хайде да не се обиждаме
сайта зарежда за около 100ms и следващите 200-300ms отваря wss, GA и ahrefs щуротите, рендва, и сайта е при потребителя за не-повече от 400-500ms! Не се подвеждай по WP феновете, те все имат недостиг на каквито и да е ресурси за да им работят сайтовете.както се казва: къде е Киро на кирия?
DerkonBG
Active Member
@metaverse може да прочетеш сравнителния анализ на ИИ:
Въпросът Ви е изключително компетентен и засяга ключови аспекти на съвременната уеб архитектура, а именно компромиса между скорост (latency) и ресурсоемкост (resource consumption) при избора на комуникационен протокол.
Краткото техническо мнение е, че WebSockets (WS) е по-бърз и по-малко ресурсоемък на ниво мрежов трафик за приложения, изискващи комуникация в реално време (като "live search" или autocomplete), но може да бъде по-ресурсоемък на ниво сървърна памет за голям брой неактивни потребители.
По-долу представям детайлен анализ, който сравнява двата подхода – традиционните HTTP заявки (GET/AJAX) и WebSockets – в контекста на реализация на търсачка.
Извод за Скорост: За сценарий като "търсене в реално време" (live search), където потребителят въвежда символ по символ и очаква незабавни резултати, WebSockets е значително по-бърз поради елиминирането на повтарящия се HTTP overhead.
Извод за Ресурсоемкост:
Технически анализ: WebSockets срещу AJAX/GET за реализация на търсачка
Уважаеми потребителю,Въпросът Ви е изключително компетентен и засяга ключови аспекти на съвременната уеб архитектура, а именно компромиса между скорост (latency) и ресурсоемкост (resource consumption) при избора на комуникационен протокол.
Краткото техническо мнение е, че WebSockets (WS) е по-бърз и по-малко ресурсоемък на ниво мрежов трафик за приложения, изискващи комуникация в реално време (като "live search" или autocomplete), но може да бъде по-ресурсоемък на ниво сървърна памет за голям брой неактивни потребители.
По-долу представям детайлен анализ, който сравнява двата подхода – традиционните HTTP заявки (GET/AJAX) и WebSockets – в контекста на реализация на търсачка.
1. Сравнение по отношение на Скорост (Latency)
Скоростта, или по-точно латентността (latency), е основният фактор, където WebSockets има предимство.| Характеристика | HTTP/AJAX (GET) | WebSockets (WS) |
|---|---|---|
| Връзка | Stateless (без състояние). Всяка заявка изисква установяване, поддържане и затваряне на нова TCP връзка (или повторно използване чрез Keep-Alive, но с нов HTTP handshake). | Stateful (с поддържане на състояние). След първоначалния HTTP/WS handshake, връзката остава постоянно отворена (persistent). |
| Overhead | Висок. Всяка заявка носи със себе си пълни HTTP хедъри (бисквитки, потребителски агент, метаданни), което увеличава размера на пакета. | Нисък. След установяването, комуникацията се осъществява чрез малки фреймове (frames), които имат минимален хедър (обикновено 2 до 10 байта) [9]. |
| Латентност | По-висока. Времето за изграждане на HTTP заявката и обработката на пълните хедъри добавя забавяне към всяко търсене. | По-ниска. Данните се изпращат и получават почти мигновено по вече установената връзка, което е идеално за ниска латентност [10]. |
Извод за Скорост: За сценарий като "търсене в реално време" (live search), където потребителят въвежда символ по символ и очаква незабавни резултати, WebSockets е значително по-бърз поради елиминирането на повтарящия се HTTP overhead.
2. Сравнение по отношение на Ресурсоемкост
Ресурсоемкостта трябва да се разглежда на две нива: мрежов трафик (bandwidth) и сървърни ресурси (CPU/Memory).А. Мрежов трафик (Bandwidth)
WebSockets е по-ефективен по отношение на мрежовия трафик.- HTTP/AJAX: За всяка заявка се изпращат и получават пълни HTTP хедъри. При често търсене (напр. 10 заявки за 10 въведени символа), този повтарящ се хедър натрупва значителен и ненужен трафик.
- WebSockets: След handshake-а, WS предава само минимални фреймове. Това води до до 90% по-нисък overhead в сравнение с HTTP за голям брой малки съобщения [9].
Б. Сървърни ресурси (CPU/Memory)
Тук сравнението е по-нюансирано и зависи от броя на потребителите и тяхната активност.| Ресурс | HTTP/AJAX (GET) | WebSockets (WS) |
|---|---|---|
| CPU (Обработка) | По-високо натоварване на CPU за всяка заявка, тъй като сървърът трябва да обработи пълния HTTP протокол, да установи нова връзка и да я затвори. | По-ниско натоварване на CPU за всяко съобщение, тъй като обработва само леки фреймове. Сървърът може да обработи много повече заявки в секунда [7]. |
| Памет (Memory) | По-ниска консумация на памет за неактивни потребители. Сървърът не поддържа отворена връзка, когато няма активна заявка. | По-висока консумация на памет за голям брой неактивни потребители. Всяка отворена WS връзка изисква поддържане на състояние и буфери в паметта на сървъра [12]. |
Извод за Ресурсоемкост:
- За активни потребители и голям обем данни: WS е по-ефективен и по-малко ресурсоемък за CPU и мрежата.
- За голям брой неактивни потребители: HTTP/AJAX е по-добър, тъй като не поддържа хиляди или милиони отворени, но бездействащи връзки.
3. Приложение за Търсачка: Препоръка
Изборът на технология зависи от потребителското преживяване (UX), което искате да постигнете.Сценарий 1: Стандартна търсачка (с бутон "Търсене")
- Описание: Потребителят въвежда целия си термин и натиска бутон.
- Препоръка: HTTP/AJAX (GET). Тъй като комуникацията е еднократна, ползите от WebSockets са минимални и не оправдават сложността на поддържане на постоянна връзка. AJAX е по-прост за имплементация и по-добре се вписва в модела "заявка-отговор".
Сценарий 2: Търсене в реално време (Live Search / Autocomplete)
- Описание: Резултатите се филтрират или показват предложения с всяко натискане на клавиш.
- Препоръка: WebSockets. В този случай, WebSockets е значително по-бърз и по-малко ресурсоемък по отношение на мрежовия трафик. Постоянната връзка осигурява незабавна обратна връзка, което е критично за отлично потребителско преживяване.
4. Обобщена таблица за сравнение
| Критерий | HTTP/AJAX (GET) | WebSockets (WS) |
|---|---|---|
| Основен модел | Заявка-Отговор (Request-Response) | Двупосочен, Пълен Дуплекс (Full-Duplex) |
| Латентност | Висока (заради overhead) | Ниска (след handshake) |
| Мрежов Overhead | Висок (пълни хедъри) | Нисък (минимални фреймове) |
| Сървърно CPU | Високо натоварване на заявка | Ниско натоварване на съобщение |
| Сървърна Памет | Ниска за неактивни потребители | Висока за голям брой неактивни връзки |
| Сложност на Имплементация | Ниска (стандартен уеб модел) | По-висока (изисква специализиран сървър) |
| Подходящ за Търсачка | Стандартно търсене (с бутон) | Търсене в реално време (Live Search) |
DerkonBG
Active Member
Добре че ги разбираш нещата че да се изходиш по въпроса!
Като си толкова отворен вземи си плати за DDOS услуга и ме събори! Но когато го правиш се обади и на @MegaKaloyan (той си знае защо) и после коментирай извънземните технологии който ползвам!