A Google hivatalos webfejlesztőknek szóló blogjában arra kér minket, hogy a dinamikusan (értsd: adatbázis jellegű forrásból) kiszolgált tartalmakat ne rejtsük statikus (értsd: GET paramétereket nem tartalmazó) URL-ek mögé. Szerintem hülyeséget beszélnek (ingyensört osztogattak?), de ezt kiegészítem azzal, hogy érdemes figyelni egyes tanácsaikra.
A blogban definiálják azt, hogy szerintük mi a statikus, és mi a dinamikus webcím:
Mi a statikus URL?
A statikus URL nem változik, és tipikusan nem tartalmaz URL paramétereket. Így néz ki például: http://www.example.com/archive/january.htm. Statikus címekre a Google keresőjében a filetype:htm definiálásával tudsz keresni. Az ilyen oldalaknak a a frissítése időigényes lehet, főként ha a tartalom mennyisége gyorsan nő – minden egyes oldal ugyanis kézzel készül. Emiatt a sok oldalból álló, gyakran frissülő oldalaknak, mint például a webáruházak, fórumok, blogok és tartalomkezelő rendszerek, dinamikus URL-eket célszerű használnia.
Nem igazán értem, hogy 2008-ban miért kell a DOS-os időkből ránk maradt HTM kiterjesztéssel példálózni, és hogy mi köze van a dinamikusan előálló tartalmaknak ahhoz, hogy dinamikus címet kéne használnunk. De nézzük a dinamikus URL definíciójukat:
Mi a dinamikus URL?
Ha egy oldal tartalma adatbázisban van tárolva és onnan van kiszolgálva a felhasználó kérésére, dinamikus URL-ek használata a célszerű. Ebben az esetben az oldal alapvetően egy sablonként szolgál a tartalom számára. Általában egy dinamikus URL így néz ki: http://code.google.com/p/google-checkout-php-sample-code/issues/detail?id=31. Egy dinamikus URL-t a benne levő ? = & karakterek segítségével tudsz felfedezni. A dinamikus URL-eknek megvan az a hátrányuk, hogy a különböző URL-ekhez ugyanaz a tartalom tartozhat. Vagyis egyes felhasználók esetlegesen különböző címeket használnak ugyanarra a tartalomra való linkeléskor. Ez egy ok, amiért a webfejlesztők statikus címekké szeretnék alakítani az URL-eket.
Ezt a logikát nem értem (vagy az angolom bűn rossz, és teljesen félrefordítottam – lehet). A statikus-dinamikus URL definícióját el tudom fogadni, avagy ha vannak GET paraméterek egy URL-ben, akkor hívjuk dinamikus címnek, ha nincsenek, akkor pedig statikus címnek. Az, hogy ezek az oldalak éppen adatbázisból, lemezről, memóriából, TDK SA90 High-Bias kazettáról vagy éppenséggel a nagymama lyukkártyájáról érkeznek, azt viszont nem mosnám össze azzal, hogy hogyan néz ki a címük.
Az ma már elég evidens megoldás, hogy a nagyon kis, vagy speciális weboldalak kivételével szinte mindenhol dinamikusan, programkód segítségével történő oldalkiszolgálás van a háttérben. Az is biztos, hogy azokat a tartalmakat, melyek jellemzően nem változnak az idő során, célszerű statikus URL-eken kiszolgálni.
A Google tanácsát nem szeretném azonban megfogadni. A http://webakademia.hu/2008/09/dinamikus-vagy-statikus URL ugyanis bár dinamikusan van kiszolgálva, de statikus, a hozzászólások és az oldalsáv kivételével változatlan tartalmat jelöl, és ha a hozzászólásokat vagy az oldalsávot viszonylag ritkán indexeli le a Google, akkor sincsen nagy gond. Ez az URL emberbarát, linkeléskor látni hogy várhatóan milyen tartalom van a cím mögött, sőt, még azt is, hogy milyen régi az a tartalom. Hozzáteszem, maga a Google alakíttatta ki velünk ezt a címet, mivel az URL-ben levő szöveges információt is felhasználja, és pozitívan díjazza a tartalmak rangsorolásakor.
De ez csak a bevezetése volt a bejegyzésnek, még folytatódik:
Statikussá alakítsam a dinamikus címeimet?
Íme néhány pont ami szem előtt tartandó a dinamikus URL-ekkel történő munka során:
- Elég nehéz helyesen létrehozni és karbantartani azokat az újraírókat, melyek a dinamikus címeket statikusnak tűnő címekké alakítják.
- Sokkal biztonságosabb az eredeti dinamikus cím kiszolgálása felénk, és a problémás paraméterek felismerésének és kezelésének ránk bízása.
- Ha át szeretnél írni egy címet, a dinamikusnak tűnő címek kezelésekor távolítsd el a felesleges paramétereket.
- Ha statikus URL-en szeretnél kiszolgálni dinamikus URL helyett, hozd létre a statikus párját a dinamikus tartalmadnak.
Az első pont nettó hülyeség. Ma már szinte a kezdő programozó is le tudja kezelni a statikusnak tűnő, ember- (és kereső-, de psszt) barát címeket, és a legtöbb CMS rendszer támogatja is azokat. Nem nehéz.
A kettes pontot illetően szép, hogy a Google saját magából indul ki, de azért mégiscsak úgy érzem, hogy nem a Google robotjának kényelmét kellene kiszolgálnom akkor, amikor eldöntöm, hogy milyen URL-eken szolgálom ki egy weblap bizonyos tartalmát. Ráadásul nem tudom, hogy miért lenne biztonságosabb rábízni a Google-re ezt a feladatot, amikor nagyon sokat tudok nekik segíteni akkor, amikor jelzem hogy mi a stabil, állandó tartalom az oldalon (statikus URL), és mi az, ami viszonylag gyakran változik, és a tartalom nagyban függ az URL-ben levő paramétertől (dinamikus URL).
A harmadik és negyedik pont ebben a megfogalmazásban nehezen feldolgozható.
Ezután FAQ jellegűen megpróbálnak eloszlatni pár tévedést, melyet most nem idéznék, de összefoglalnék és hozzáfűzném a személyes véleményemet:
- A bejegyzés írója szerint tévhit, hogy a statikus/statikusnak tűnő URL-ekből álló oldal indexelése könnyebb lenne. Ők is jelzik, hogy a statikus URL-ek előnyösek lehetnek mert felhasználóbarátabbak. Ennek ellenére jelzik, hogy a dinamikus címeket kellene favorizálnunk a statikus helyett. Valahol értem a logikát, azt, hogy egy dinamikus URL-ekből álló oldalcsoport leindexelése, feldolgozása könnyebb lehet, de az teljes homály számomra, hogy a felhasználóbarát megoldással szemben miért javasol egy olyan megoldást a Google, amely minimális előnyt jelenthet csak számukra (szerintem ugyanúgy kezelni tudják egy statikus URL-ekből álló oldal indexelését, mint egy dinamikus URL-ekből állóét, az algoritmusban egyszerűen mást kell dinamikus résznek tekinteni).
- Szeretnék eloszlatni azt a téveszmét, miszerint a dinamikus URL-eket nem (illetve nehezebben) tudja egy keresőmotor leindexelni. Azt írják, hogy problémájuk lehet abból, ha egyes a Google számára értékes információkat hordozó paramétereket esetlegesen elrejtünk, és azt tanácsolják, hogy tartozkódjunk a dinamikus címek statikussá tételétől. A miértre nem adnak kielégítő magyarázatot.
- Azt a tévhitet is cáfolják, miszerint a 3-nál több paramétert tartalmazó dinamikus URL-ek használata gondot okozna a robotoknak. Szerintem gondot okozhat, az lehet hogy az ő robotjuk bírja a strapát.
A folytatást hanyagolnám, ugyanaz, mint amiről eddig szó volt. Még azt is megtudhatjuk, hogy a session azonosítóknak, és a nulla információt hordozó paramétereknek nem az URL-ben a helye (tudtuk). Ez az egyetlen értelmes és hasznos mondanivalója a bejegyzésnek.
A zárás:
Reméljük ez a cikk hasznos volt és segít a dinamikus címek körüli kérdések megértésében. Csatlakott bátran a vitacsoportunkhoz ha további kérdésed van.
Nem, nem volt hasznos, és ez látható a hozzászólásokból is. Mindegyikben ott a kérdőjel. Oké Juliane és Kaspar, jó vicc volt, most már viszont ideje lenne törölni vagy megmagyarázni ezt a bejegyzést. Nem április elseje van.
Eléggé elbújik a cikkben, de írják valahol, hogy kizárólag csak az indexelhetőség miatt ne használjunk URL átírást, amúgy lehetnek erre egyéb indokaink, arról meg szépen hallgat, hogy ezek az egyéb indokok nagyon is nyomósak
.
Az is hozzátartozik a témához, hogy a gyakran változó tartalmaknál elvileg nem az lenne az üdvözítő megoldás, hogy dinamikus URL-eket használunk, hanem a megfelelő fejlécekkel kell a tartalmat kiszolgálni (expires, cache, etag, stb.) – igaz ezt sem biztos, hogy jól kezeli minden kliens.
Másrészről vannak esetek, amikor a paraméterezett URL-ek használata tényleg szerencsésebb, pl. amikor arra szolgálnak, hogy ugyanazt a tartalmat különbözőképpen jeleníthessük meg: lapozási, rendezési lehetőségek, keresési paraméterek stb.
ne rejtsuk el a fontos adatokat az url-bol? meg a dinamikus cimek indexelese is ugyanolyan konnyu? Akkor ha jolertem a legjobb ha oldal.hu/fontos_info/konyvtar.php?p1=keyword1&p2=keyword2&p3=keyword3 az idealis megoldas? Ez tenyleg mekkora baromsag
nanofish: Ezzel nagyonis egyetértek, de szerintem nem ezt írták le.
Erre a mondatra gondoltam:
“While static URLs might have a slight advantage in terms of clickthrough rates because users can easily read the urls, the decision to use database-driven websites does not imply a significant disadvantage in terms of indexing and ranking.”
De aztán meg ezt írja:
“Does that mean I should avoid rewriting dynamic URLs at all?
That’s our recommendation… blabla”
Szóval a post átgondolatlan, ellentmondásos és félreérthető. Később a kommentekben is szabadkozik, hogy nem is így gondolta, hanem amúgy, meg különben is annak a tudatában írta a cikket, hogy nagyon sok webmester képtelen normálisan megírni a rewrite szabályokat, ami elég béna magyarázat.
Szerintem az lehetett, hogy eszébe jutott valami és be is küldte, mielőtt kellő mélységben átgondolta volna a témát, aztán még meg is próbálta védeni a hülyeségét.
Így járt, hülyét csinált magából, mindenkivel előfordulhat ilyesmi
)
hi,
szerintem az eredeti Google cikk teljesen ertheto. Sok kliensemnek eredendo SEO maniaja, hogy mindenkepp valami UrlRewrite komponenssel turkaljuk at az adatbazisbol parameterekkel szarmaztatott oldalt (ergo: example.org/valami.aspx?e=termekek&pid=1234 helyett legyen example.org/termekek/1234), ergo ez egy szep kis pluszfeladat, tekintve hogy kell egy link-formazas osztaly a kimeno, illetve egy ISAPI/HttpHandler a bejovo linkekre. Eddigi tapasztalatom is az volt, hogy felesleges a moka – barmilyen explicit parametert megeszik a GoogleBot; nyilvan okos ember a Sessiont meg az Authot eddig sem tarolta benne.
Lamantin, ha a site logikusan van felepitve, a parameterezett Urlekkel sincs baj (lapozas, rendezes) es kezeli is a GoogleBot rendesen – a lenyeg az, h azonos Urlre azonos tartalmat szolgaljon ki az alkalmazas *mindig*.
balint: Az example.org/termekek/palacsintasuto a helyes megfejtés, és ennek bizony még értelme is van. Szerintem a valami.aspx elég randán néz ki, és a megrendelőnek jogos igénye, hogy szebb legyen a link, könnyebben gépelhető, jobban megjegyezhető. Azért a 10-20 sorért, és 30 perc munkáért pedig ugyan már, ne panaszkodjál itt nekem.
valami.aspx: nemcsak csúnya, de a kiterjesztést mindenképpen tanácsos elbújtatni. Az igények változhatnak és egy technológia váltáa az összes oldalunkra mutató linket érvénytelenné teszi, ha benne van az URL-ben a kiterjesztés. A W3C még a képek és egyéb média esetében is ezt javasolja, mert a technológia itt is változhat (lsd. gif=>png, mp3=>ogg).
Google mostmár monopólium, úgyhogy ahelyett, hogy fejlesztené a robotját, zsarolja a honlapokat, hogy az elvárt módon csináljanak mindent, így a Googlenek nem kell fejlesztenie. Sokkal olcsóbb kizárni a renitens honlapokat, mint normális robotot fejleszteni.
@barthazi andras: a title/keywords/text optimalizacioban hiszek, nem az urlben (az elmult 8 ev tapasztalatai)
@nanofish, miert lenne technologiavaltas? monoval freebsdn hostolunk
egyebkent meg vannak ilyen projektjeink, amikor eppen a meglevo cifra urleket (meglepodnetek mik vannak benne:) ) kell megtartani az elokelo google pagerankjuk/helyezesuk miatt (mivel ezen realizalodik a t. megrendelo beveteleinek 85%-a)
@bálint:
Technológiaváltás egy csomó minden miatt lehet, fantázia kérdése leírni egy csomó lehetséges és életszerű okot, az a titka, hogy nem 1-2, hanem 5-10 vagy ennél is több éves időkeretben kell gondolkodni. Csak abba gondolj bele, hogy 10 évvel ezelőtt mik voltak az URL-ekben (/cgi-bin/szkript, meg /szkript.pl), meg most mik vannak és hogy akkoriban hol voltak azok a technológiák, amiket ma használsz. Még inkább elképzelheztő, hogy CMS-t vagy keretrendszert cserélsz, ekkor a paraméterezéssel máris bajok vannak.
A megfelelő URL-tér kialakítása nem olyan dolog, hogy egy majdani esetleges követelmény miatt dolgozunk most heteket, hanem arról szól, hogy egy majdani nagyon is valószínű szívást kerülhetünk el egy pár órás munkával. Szvsz ez megéri.
A másik ok, a törött backlinkek elkerülése pedig a web egészének minősége miatt fontos. Elvileg 404-es hibának tényleg csak félregépelés miatt szabadna előfordulnia ennek ellenére tele van velük a web.
@Bence:
Azért ennyire nem súlyos a helyzet, mindössze annyiról van szó, hogy egy Google-alkalmazott írt egy átgondolatlan posztot
. A Google-nak is nagyon fontos, hogy a lehető leghatékonyabb módon szedjen ki információt az oldalakból. Szerintem nagyon is sok melót feccöltek bele, hogy teljesen össze-vissza, szintaktikailag hibás oldalakból is kinyerjenek valamit, ha ott van valami érdekes.
@balint: az én látogatóim azért többségben még mindig emberek és nem botok, így elsősorban rájuk optimalizálom a címeimet, nem a Google-re. Második körben nyilván arra is, de nehogymár azért kerülgessék az emberek a “.aspx”-t, meg a “&pid=”-t hogy a Google-nek jó legyen…
@nanofish, @marcell: meg egy gondolat, h egyertelmubb legyen amit fent leirtam. en alapvetoen ket csoportba gyujtom egy sitenal az urleket: a) amelyek “kiemeltek”, ergo sitemapben, google kampanyokban szerepelnek b) a “technikai oldalak” amelyek a listazast, keresest etc. szolgaljak ki, ezek viszont nem feltetlen kell, hogy pageranket és/vagy talaltot adjanak (!), eleg ha a google indexben benne vannak. 500-800.000 rekordnal es a szarmaztatott kb. 23.000.000 tetszoleges dinamikus oldalnal mar elgondolkodik az ember, hogy milyen urlrewrite-ot enged amelyek atlag 12-30% (!) CPU cycle-t tudnak elvinni egy-egy keres feldolgozasanal, tobbnyire feleslegesen – persze lehet meg 10-15 szervert beallitani a celra, de azt fianszirozza az, aki reszvenyes a Google-ban
Egyebkent most komolyan: van olyan ember, aki nem copy+paste-el egy Urlt? ott meg nem halal mindegy, hogy milyen a link olvashatosaga? Amazon.com linkeket lattatok mar?:)
@nanofish: en biztos nem valtok technologiat; ha kiszolgalt az elmult 6-7 evben, ki fog szolgalni a kovetkezo 6-7 evben is. Komoly, tokeeros uzleti vallalkozasok *sem* szoktak kihuzni ennyi ideig a (kozep-kelet europai) weben…:)
Sziasztok!
Eléggé érdekes, hogy a változást, vagy az arra utaló híreket a Google a CHROME megjelenésével majdnem egy időben kezdi kiszivárogtatni!
???
A KÉRDÉS
Miért fejlesztene a Google egy böngészőt, és miért turbózza úgy fel a a kereső motorját ahogy azt tette, ha rosszak lennének számára a “example.org/valami.aspx?e=termekek&pid=1234″ linkek? | Idézet Bálint hozzászólásából |
A Chrome (leírása alapján) képes lesz ezt kezelni, és én ebben látom az igazi veszélyt!
(!Megjegyzem, én nem használom a CHROM böngészőt, mert egy fórum tanulsága szerint elolvastam, amit elfogadtam a telepítés során, és az óta sem térek magamhoz! Ezzel nem szeretnék senkit befolyásolni arra, hogy használja vagy sem, ezt a remek fejlesztésekre alapuló böngészőt! Szó sincs róla! Mindenki eldöntheti mit fogad el feltételként egy software telepítése során.!)
Amennyiben neked lenne birtokodban a világ leghatalmasabb marketing cége, és ezt a pozíciót szeretnéd is megtartani, nem csinálnál egy böngészőt, ami a “szemétből” is kihalássza azt, ami értékes?
Így ezek után már nem csak a kiváló SEO munkáját láthatod a keresők első helyén, hanem minden olyat, amire az emberek valóban azt mondják ” Ó ez nagyon jó oldal! Pont ezt a valamit kerestem!” Ezt tudja a CHROME! (az én felfogásom szerint!)
Miért jó ez?
Kinek jó egy ilyen találati lista?
Szerintem:
Az olyan nagy PR értékkel rendelkező oldalaknak, akik naponta több száz auto generált oldalra öntik fel ipari mennyiségű, valóban MINŐSÉGI tartalmaikat.
Igen ám, de ezeket a gigászi oldalakat hamar megelőzik az “ifjú” lelkes SEO guruk, akik töredék idő alatt az első 5 találatba ékelődnek be oldalaikkal az adott releváns témák közé!
Ekkor a NAGY hirdetők, feltehetik a kérdést a Google számára, hogy, miért van az, amikor ŐK dollár milliárdokat áramoltatnak a Google felé hirdetési kampányok formájában, akkor XIEN QUNG (kitalált név) pont 10x többet ad el egy valamilyen termékből, csak azért mert az Övé 47 aloldal, és pont 20% energiával KICSINOSÍTHATTA (SEO) úgy, hogy 2 hét alatt megelőzte az amazon.com termékeit!
Ja, és ezt elérte max. 2000$ tőkével úgy, hogy még a napi 2 pizzát is beleszámolta!
hahaha!
Ez nem szép kép a valóságról! Sőt fáj, mert érint mindenkit, aki tette ezt ETIKUSAN, sőt azt is aki pont ellenkezőleg (BLACK HAT) nyomta!
Te mit tennél, ha te lennél a Google?
Hagynád a cápákat elúszni egy másik vidékre, csak hogy végre kishalazhass egy kicsit, mert az FUN? Vagy TENNÉL (bejelentenél) valamit ami a maradásra készteti Őket?!
Amennyiben Te lennél az Amazon, vagy Virgin (stb.) és segítettél aktívan felnevelni két fiatal srác által zseniálisan megalkotott kereső szisztémát, akkor hagynád, hogy XIEN QUNG (kitalált név) letaszítson, onnan ahol valóban a TE helyed van?
Ráadásul több millió dollárt költöttél el átkattintásokra, hogy az ELSŐK közt lehess!
(XIEN QUNG szerintem havi 100$ költ adwords-re, és azt is csak azért, hogy megtudja az Amazon marketing gyengeségeit!)
Valljuk be az IGAZAT! (?? !!)
Én nem hagynám egyik esetben sem!
A bejelentésben, egyszerűen csak az van, hogy akik eddig szépen csinosítgatták az oldalakat, és a linkeket (ezt sajnos ETIKUS módszerekkel kevesen tették) lehet, hogy nem élveznek majd előnyt a versenyben!
A KERESŐ (SEO,SEM) szakma alapjait létrehozó nagy testvér (Google)is pénzből él! (én 10% részvénnyel is beérném) Mi pedig kiismertük ŐT, és a hihetetlen rafinériával felépített TITKOS fegyverét manipuláljuk napi munkáink során! Ki hogyan, viszont Én tiszta eszközökkel teszem azt!
Gondolj bele! A reklámok után járó bevétel felmérhetetlen nagy összeg lehet!
A giga site-ok hatalommal bírnak, a hatalom pénz! Amennyiben hatalomba akarsz maradni támogatnod, kell azokat, aki oda eljuttattak!
Kérlek menj az említett oldalak valamelyikére, és szörnyülködj a linkek láttán!!! Megérted mind azt, amit írtam! Amennyiben nem, akkor nem Téged érint!
Mi pedig kedves SEO barátaim, majd újra kitaláljuk, hogy hogyan kell ezt a magunk javára fordítani!
Ez a játszma megy már egy ideje, és ettől olyan érdekes!
Sok volt! Tudom! Nem tudtam ezt most rövidebben!
Köszönöm!
TAMÁS
Tom: Ne sértődj meg Tamás, de ez így szimpla hülyeség.
Kedves András!
Nem sértődöm meg akkor ha kifejted mi a “szimpla hülyeség” számodra!
Sok értelmes ötlet vérzett már el az élet színpadán, mert egy hangos szó azt mondta, hülyeség! Lehet, hogy nem tetszik, lehet, hogy nem érted, lehet, hogy mást szeretnél kapni, viszont túl egyszerű értékelése lenne a nézőpontomnak “szimpla hülyeség”!
Fejts ki kérlek, hogy lássam mi az ami kiváltotta belőled ezt a “választ”!
Köszönet érte!
TAmás
Tom: Mert a Chrome egy WebKit alapú böngésző, és kb. se többet, se kevesebbet nem tud, mint az Apple által kiadott Safari. Ennek kapcsán nullához közelít az összefüggés mértéke a két hír között, ráadásul amiről itt szó van, az egy szimplán béna, komolyan nem igazán vehető bejegyzés.
balint: Te lehet hogy nem váltasz technológiát. És az ügyfél fejlesztőcéget?
balint: Nem csak a “kézzel begépelés” a lényeg, hanem az is hogy az URL-ből kiderüljön mi van mögötte. Az oldalak számának és a látogatottságnak az összefüggése pedig minimális, tökmindegy mennyi lehetséges oldalad van, nem azok mennyisége fogja a szervered beterhelni. 12-30% CPU terhelés növekedés kapcsán ugye 12-30%-kal több szervert kell beállítani (durva egyszerűsítéssel), tehát a szerverek számának hatalmas növekedését idekeverni is rossz ötletnek tűnik. Egy lightosabb webszerverrel, más technológiával pedig lehet, hogy meg is tudod spórolni ezeket a százalékokat.
Hagyjuk, szerintem több szempontból is jobb az olvasható és egyben rövid URL, és én eszerint fogok cselekedni a jövőben is.
Meg úgy tűnik, hogy az eredeti blogbejegyzéshez kommentelők 99%-a is.
@András: 1) naná, majd áttér perl cgire 2) bocs, de nem érted amit írtam; nem a google használja az alkalmazást, hanem a felhasználók, ők húznak ki az adatbázisból több millió lapot. A google láthat ebből max 100.000-t, azt is tűzzel-vassal kell írtani, h ne indexeljen többet (kaptam én már googlebot-floodot). A cpu terhelés növekedése pedig ugye nem lineáris, javaslom pl. h kapcsolj egy adatbazis-szerverre +30% lekérést s nézd meg a rajta függő webserver node-ok cpu cycle növekedését. nem 30% lesz, hanem egy idő után 100%, s sorban ki fognak dögleni. Ez kb olyan helyzet, mintha a google beszabadulna az iwiwre, s rekurzívan az összes usert s kapcsolatait leindexelné, garantáltan egy hétig állna a szolgáltatásuk.
3) ha a lighttpd/xspnél mondasz kisebb footprintű webservert, kapsz egy nagy pirospont!
balint: Kezdesz erősen csúsztatni, részemről ezzel lezárom a meddő vitát.
1) Ha átmegy egy másik céghez, ahol PHP-t használnak, akkor máris szívás van. Ezt miért nehéz megérteni? 2) Arról volt szó, hogy az oldal kiszolgálása emészt fel 12-30%-kal több CPU-t a rewrite miatt, adatbázisról szó sem esett (a kérések számát illetően ugyanis semennyivel sem több a rewrite-os megoldás mint a nem rewrite-os). A CPU meg lineárisan terhelődik. Persze ha eleve csúcsra van járatva, akkor már lehet hogy nem. 3) A miner.hu-n kismilliárd féle választ kaphatsz ami az oldalak számát illeti. Mégsem használják kismilliárdan, és nem “húznak ki” kismilliárd oldalt belőle. Az adatok mennyiségének még mindig nincsen köze a felhasználói aktivitáshoz.
1) miért menne máshova? (Ezek szerint a Te ügyfeleid általában távoznak egy idő után?..) éppen azt írtam, h a) hozzám jönnek a hülye urljeikkel b) elvárják az ész nélküli felesleges rewrite-ot, ahol semmi nem igényli, a google végképp nem: lásd a cikk(!) c) nyilván adatbázisból dolgozunk nem csv fájlokból:
” hogy mindenkepp valami UrlRewrite komponenssel turkaljuk at az adatbazisbol parameterekkel szarmaztatott oldalt”
“egyebkent meg vannak ilyen projektjeink, amikor eppen a meglevo cifra urleket (meglepodnetek mik vannak benne:) ) kell megtartani az elokelo google pagerankjuk/helyezesuk miatt (mivel ezen realizalodik a t. megrendelo beveteleinek 85%-a)”
2) request -> urlrewrite -> alkalmazas -> adatbazis/cache -> response
könnyen belátható, ha valamelyik része (túl)terhelődik, ott egy bottleneck jön létre, s az újabb kérések fel-nem-dolgozása könnyen magával ránthatja a többi réteget.
3) nem azt mondtam, hogy a generált urlek száma összefüggésben van a terheléssel, hanem azt, hogy én olyan esetről beszélek, amikor fix felhasználói bázis elviszi az alkalmazás erőforrásainak 50%-át 365/24, a google-ből jövők nélkül; s az utóbbi okozott fejtörést, amikor elvitte a maradék 50%-ot egy jól irányzott indexeléssel (amikor elkezdte végigmászni a /valami.aspx?param=¶m2= oldalakat, amit addig ugye nem csinált).
Nincs annál reménytelenebb helyzet, amikor ül az ember a console előtt, s látja özönleni be az elképesztő mennyiségű kérést (illetve már csak azt látja, response-t meg nem), s a performance monitoron meg a 100%-os csíkokat az egész webfarmon.
A személyeskedést viszont abszolúte nem értem; én a való életből vett példákat írtam segítő jelleggel, hogy esetleg más ne szopja be, amin én már átmentem; de úgy látom itt mindenki annyira vágja a témát, hogy felesleges koptatnom a billentyűket.
Bálint, nem lehet, hogy egy DOS támadást kaptál ahol GoogleBotnak hazudták magukat a lekérésben? Én hiszek annyira a GoogleBot fejlesztőiben, hogy figyelnek arra, hogy ne lehetetlenítsenek el site-okat.
Jano: nem, a google-nek dedikalt ip zonai vannak.
András!
balint azt írta:
A személyeskedést viszont abszolúte nem értem; én a való életből vett példákat írtam segítő jelleggel, hogy esetleg más ne szopja be, amin én már átmentem; de úgy látom itt mindenki annyira vágja a témát, hogy felesleges koptatnom a billentyűket.
Én már nem írom le ugyanazt a saját hozzászólásommal kapcsolatban!
Viszont hasonlóan cselekszem! Jó (le)értékeléseket neked!
Tom!
Nem kell felkapnod a vizet! Szerintem erre a bejegyzésre írta András:
http://webakademia.hu/2008/09/dinamikus-vagy-statikus/#comment-2329
“elgondolkodik az ember, hogy milyen urlrewrite-ot enged amelyek atlag 12-30% (!) CPU cycle-t tudnak elvinni egy-egy keres feldolgozasanal”
Balogh Tibor: Erre írtam hogy szimplán felesleges összeesküvés elmélet, és a Google bejegyzését minősítettem bénának. Ezeket akkor is tartom ha ez személyeskedésnek minősül – kifejezetten felidegesít ugyanis ha valaki a blogomon hülyeséget ír (spekulálni lehet, de a Google ezen lépése csak segítette a piacot, és naponta jönnek ki valami újdonsággal, felesleges két független között összefüggést keresni).
Azt a 12-30%-ot is furcsállom, de nem ellenőriztem le, így nem tudom hitelesen minősíteni. De nem ez volt a gondom Bálint hozzászólásával, hanem hogy úgy tűnik nagyon nem értünk egyet abban hogy egy URL-nek technológia- és kivitelezőfüggetlennek, a tartalomra rámutatónak kell lennie, nem csak SEO, hanem felhasználóbarátság szempontjából is, még ha egy kicsit több erőforrást is eszik így egy cucc. Legalábbis erre mutat az összes trend, és több előnyt tudok felsorolni, mint hátrányt. Erre is szánnom kéne egy kis időt, és átolvasni az idevágó URL szabványokat és ajánlásokat hogy mit írnak az URL-ben a path és a query részek viszonyáról, használatáról.
“amelyek atlag 12-30% (!) CPU cycle-t tudnak elvinni”
Azért azt megnézném, hogy ezt hogy sikerült kihoznod, szerintem ott valami nagyon nem stimmel. Hogy mérted ezt?
@Hodicska Gergely: C# profiler + SQL Profiler
“ha a lighttpd/xspnél mondasz kisebb footprintű webservert, kapsz egy nagy pirospont!”
Nginx?
Bocs, hogy ilyen dadógosan nyomom.
“kapcsolj egy adatbazis-szerverre +30% lekérést s nézd meg a rajta függő webserver node-ok cpu cycle növekedését. nem 30% lesz, hanem egy idő után 100%, s sorban ki fognak dögleni.”
Ezt kifejtenéd kicsit bővebben?
Komolyan mondod, hogy egy dinamikus oldal kiszolgálásából, ami ráadásul még DB-hez is nyúl, 12-30% a rewrite? Bár nem dolgoztam .NET-tel, de ez elég durva, valami ott nem kerek (rosszul van használva), vagy pedig nagyon gyenge ott a rewrite.
Ha senkit nem érdekelne, hogy milyen az URL, használhatnánk tinyURL típusú rövidítéseket minden oldalhoz (inkl. paraméterátadás p1=v1 etc). Én a részemről az olvasható URL-t szeretem, és ha nem is muszáj, hogy egy blog esetében a címben megtalálható legyen a dátum, azért jó látni a bejegyzés címét. Eldönthetem, hogy akarok-e kattintani, vagy sem.
Ahogy András is írta, nem a Google Botnak készíti az ember a weboldalt, hanem a felhasználóknak, akik – ha csak a ‘sima’ http linket látják – jobb szeretik látni, hogy mire klikkelnek.