Sziasztok,
szeretném a segítségetek kérni adatbázis teljesítményének optimalizálásával kapcsolatban, mert a szolgáltatómtól kaptam egy levelet, hogy:
---
Oldalad kritikusan sok MySql lekérdezést futtat, annak ellenére, hogy oldalad látogatószáma relatív alacsony.
Látogatók száma naponta: 1500-2000
A mai napon futtatott lekérdezések száma: 692.971
Az összes lekérdezéshez képest a szerveren: 7.99 %
A statisztikából látszik, hogy oldalad annyi adatbázis műveletet végez, mint másik 500 oldal, így igen nagy terhelést generál. Mivel ez veszélyezteti a szerver és más oldalak stabilitását tárhelyedet korlátoztuk, az érintett két oldalt (ami a xxx adatbázist használja) átmásoltuk a "_old" mappába, de cPanel elérésed továbbra is működik. Megkérlek az oldalt jelenlegi formájában ne tedd vissza!
Megoldás lehet az oldal optimalizálása, vagy cache használata. Ha valamilyen publikus rendszert használsz (például Joomla, WordPress, Drupal) akkor a cache egyszerűen telepíthető plugin-ként is. Ha kérdésed van, segítünk a megválaszolásában!
A tárhelyed a mysql lekérdezésen túl CPU-ból is igen sokat használ, így mindenképp indokolt valamilyen cache bekapcsolása.
---
Valóban "elfelejtettem" bekapcsolni a "admin/config/development/performance" helyen lévő cache-t. Ezen felül tudok még valamit tenni szerintetek? Létezik egyéb modul ami tud gyorsítani a lekérdezéseken?
Üdv.
KALMI
Ha csak tarhelyed van akkor
Ha csak tarhelyed van akkor eleg sokban bekorlatoz a szolgaltatod, nem hiszem hogy a tarhelyen kivul "sok mast is ad".
Egyebkent valoban vannak modulok:
http://drupal.org/project/memcache
http://drupal.org/project/apc
http://drupal.org/project/varnish
de szerintem azek kozul egyet sem birsz hasznalnai egy sima tarhelyen.
Aztan van meg a http://drupal.org/project/boost modul is ami meg dev a 7-eshez.
Na de majd nalam okosabbak megmongyak a tutit, kulonben a szamok amiket irtal eleg realisnak tunnek...Lehet elkellene gondolkoznod azon is hogy szolgaltatot valtasz...
Server gyorsítás
Viszont ezek a modulok okoznak érdemi javulást vagy csak a servert fogom megint terhelni?
Az is kerdeses hogy mit tamogat a szolgaltato ezek kozul
Ha a szolgaltato nem ad hozzaferest a memcached -hez vagy az apc -hez vagy nincs is telepitve a gepen akkor a te esetedben az felejtos tudtommal. Ugyanaez ervenyes a varnishra is. Ha birod iket hasznalni akkor egyreszt csokkentik a gep terheleset masreszt javul az oldald kiszolgalasa is. Pl. a memcached nagyonjol hasznalhato hogy a mysql -rol levegyuk a terhellest.
En mindenesetre rakerdeznek a szolgaltatora hogy van a lehetoseg memcached vagy mas cache hasznalatara, mert ez toluk fugg. Varnish ra szerintem semmi eselyed egy egyszeru tarhelyen.
Marad a boost modul, azt nem tudom milyen allapotban van a hetesben latom meg dev sot irja is hogy nem minden mukodik benne ...
Egy egyszeru sima tarhelyen szerintem szinte csak az admin/config/development/performance marad ott kipipazod a Cache pages for anonymous users es a Cache blocks a Minimum cache lifetime -nel meg attol fuggoen hogy mennyire valtozik az oldalad dinamikusan azt az idot allitod be aminek el el kell mulni mieleott ujbol generalja a blokkodat. Az Expiration of cached pages nal meg azt allitod be hogy max meddig szedheti az adatokat a cache bol ...
Egy nagyon ritkan valtozo oldalnal ahol egyszer megirnak mindent es szinte tobbet meg sem valtoztatjak ott ez is eleg sokat tud segiteni.
A boost modul (ha jol tudom) foleg/szinte a nem belepett vagyis anonim felhasznaloknal vagyis latogatoknal segit sokat a terhellesen.
Az is erdekes lenne hogy azok a latogatok valojaban mit is csinalnak az oldaladon, mert ettol is fugg hogy mit es mennyire lehet cachelni. Regisztralt es belepett felhasznalok?
Hát igen ezeket a
Hát igen ezeket a paramétereket, hogyan lehet lekérni? (ha valami nincs engedélyezve arról kapok információt?)
Az oldalam elvileg semmi extrát nem csinál több nyelvű oldal sajnos sok modul fut benne, mert amit tapasztalok, hogy vagy modult telepítek és lehet szabványos módon Drupalon keresztül beállítani dolgokat, vagy beleírok a kódba...
(amit tudok kikapcsolok így is)
Esetleg ötleted van azzal kapcsolatban, hogy mely modulok szokták leterhelni az adatbázis erőforrásait?
Segítségedet köszönöm!
Üdv.
KALMI
En pl. irank a szolgaltatonak
En pl. irank a szolgaltatonak, ha mar megtiszteltek hogy irtak nekem, sot meg azt is emlitik hogy ha kerdesed van szivessen allnak a rendelkezesedre. Ha mar ilyen korrektul es pozitivan allnak hozza a dologhoz akkor szerintem nem dol ossze a vileg ha rakerdezel hogy milyen cache megoldast tamogatnak ok is? Van-e lehetoseg peldalul a memcached hasznalatara?
Nem irtad azok az oldallatogatok belepett regisztralt user-ek vagy csak ugy rigisztracio es belepes nelkul nezegetik az oldalaid?
A blokkok es az oldlalak gyorstarazasat bekapcsoltad az alapban? Beallitottad a ket idot is?
Picit rosszul erted szerintem a drupal "filozofiajat" az is szep drupalos megoldas ha beleirsz a kodba, salyat modulokat hozol letre. Es akkor jobban birsz vigyazni is arra hogy az minnel kevesbe legyen terhelo. Persze ez nem azt jelenti hogy magaban a drupal vagy a sminkek vagy a modulok kodjaban javitgatsz, megvan annak a rendes drupalos modja hogy hogyan kell azt csinalni. A netrol letoltott kodokba sosem javitunk bele mert egy frissites felul is irhatja a modositasaidat.
Lehet regisztrálni, de még
Lehet regisztrálni, de még előnyökkel nem jár, azaz jelenleg nincs használva ez a funkció még. Így ebből adódó hibák nem lehetnek.
A Drupalban található gyorsításokat mind bekapcsoltam.
A szerkesztéseknél pedig inkább a sminkel kapcsolatos dolgokra gondolok és inkább modult telepítek, ha létezik rá modul (pl: SEO megoldások stb...). Bonyolultabb memóriára kihatással lévő változtatásokat nem csinálok a Drupalban.
---
Ennek ellenére mai is kaptam levelet:
A CPU terhelés egyelőre megoldottnak látszik, köszönöm a gyors reakciót. Amint probléma adódik jelzem, folyamatosan figyeljük az oldalt.
A mysql eddig a mai napon: 3.54% (123.472) Ez nem kritikus, de igen soknak mondható. Mindenképp jó lenne, ha a fejlesztő megnézné mi okoz ilyen nagy számú lekérdezést.
---
A Memcahched modul milyen jellegű sebesség gyorsulást eredményezne?
Továbbá a tegnapi 2000-es forgalmam milyen hatással van a serverre, ez mekkora terheltséget okoz?
KALMI
ezekre a kérdésekre
mindre a szolgáltatód tud válaszolni. ők tudják mimennyi a szerverben, ők látnak logokat. a saját kérdésükre, hogy mi okoz ilyen nagy számú lekérdezést, szintén a szerver logjából lehet válaszolni, ezért azt is bátran próbáld elkérni. a mysql logot kérjed.
nem írtad, hogy mit csinálnak a felhasználók, kb milyen típusú az oldal. beállíthatsz nagy cache lifetimeot ahol bekapcsoltad a cachet, elvileg akkor sokkal kevesebb lekérdezés lesz. ha sok nézeted van vagy panelek, azokra is állíthatsz be cachet, azok szerkesztésekor.
-
clear: both;
Szia,
Szia,
Kértem log file-t.
Panelt nem sokat használok.
Egy sima "szolgáltatás" bemutató oldal, ahol a szolgáltatásról vannak leírások. Nem egy komplikált dolog.
Üdv.
KALMI
állítsál be akkor egy jókora gyorstár élettartamot
nincs sok új friss tartalom, nincs hozzászólások, fórum, friss ezaz, akkor állítsál be egy jókora gyorstár élettartamot, teszem azt 3 órát vagy még többet és ezzel mindent megtettél kb. ha még ez se elég, lehet boost modult is használni egy ilyen helyzetben, az tulajdonképpen konkrétan .html fileokat fog generálni az összes oldalból, ezért nulla mysql lekérdezéssel jár egy boostal kezelt page kiszolgálása. de ezt szerintem a terhelés nálad nem indokolja.
persze lehetséges olyan is, hogy a sminkedben vagy néhány viewsban csinálsz olyan dolgokat amik rengeteg lekérdezéssel járnak, ezt nem tudhatom.
és mégegyszer, ezek - konkrét adatok, kódok, miegymás híján - mind csak tippek-trükkök kategória :)
-
clear: both;
Az oldal publikus?
Az oldal publikus? Legalabb fogalmunk legyen rola hogy mirol is beszelgetunk. Nekem igy eddig az jott le hogy sima mezei nem belepett latogatokrol van szo, mivel irtad is hogy regisztralhassak magukat de az nem jar elonyokkel igy gondolom nem is regisztraljak magukat. Hany regisztralt user van ha nem titok?
Nezd meg a boost modul a 7-esen mennyire hasznalhato mar az sokat javit az ilyen nem beleleptt felhasznaloju oldalaknal ...
Szia,
Szia,
Természetesen :-), http://studyuniversity.info/ 10-es nagyságrendű, mert még nem az a acélunk, hogy regisztrált felületeink legyenek.
A tárhely üzemeltetőjének és megadtam e fórum elérhetőségét, így ők is olvassák már, ezt nagyon pozitívnak is találom :)
A szolgáltató
Sziasztok!
Örültem a sok hozzászólásnak, és mivel szeretnénk megoldani az esetet ami nem egyedi, csak esetleg máshol nincs ennyi látogató, leírok pár adatot, információt. Az oldal címét írja meg a tulajdonosa ha gondolja.
- A szervereken memcached nincsen (még lehet, de ez hosszabb folyamat), ellenben van Varnish, saját oldalaink azon keresztül mennek! Ezt azonban mi nem merjük kiajánlani, mert konfigurálni kell egyedileg minden oldalhoz. Szerintem már találtunk általános Drupal konfigot hozzá, azonban ez általában a feltelepített egyéb dolgok miatt nem megfelelő, mert POST után nem mindíg jelenik meg a frissített oldal (pl. oldal comment). A konfiguráció idő, szakértelem, pénz...
- Az említett oldal statikusnak mondható, kb. napi 2000 látogatóval, napi 4-6000 találattal. Naponta ez az oldal (tegnapi adat) 464.186 lekérdezést indított. Matek: 92 lekérdezés / page. Ma eddig 123.472.
- Sajnos a mysql query logból igen nehezen gyűjthető ki egyetlen felhasználó ténykedése. Aki látott már ilyet az tudja miről beszélek. Külön eszközök vannak az elemzésére, egyszerű szűrés nem megvalósítható rajta. Ráadásul az adatmennyiség is hatalmas, a szervereken átlagosan 300-400 lekérdezés fut másodpercenként de nem ritka a több ezres TPS sem.
Kérdés:
1. Van olyan cache esetleg, ami az oldalakat első kéréskor legenerálja, és utána csak ezeket a statikus fájlokat jeleníti meg? Pl. WordPress cache megoldások ilyenek. Kb. az összes fájl elférne memóriában zéró adatbázis művelettel, aztán óránként ezek a fájlok újragenerálódnak.
2. Ha beizzítjuk a memcached-et ezen a szerveren, ahhoz van standard plugin, ami különösebb konfigurálás és ismeret nélkül működik?
Észrevétel:
Mindenkinek javaslom, ha nagyobb marketing kampányba fog, előtte teljesítmény tesztelje oldalát (ne a szolgáltató szerverén, hanem fejlesztői gépen), és egyeztessen a szolgáltatóval is! Sok nagy látogatottságú oldalunk van, úgy gondolom a megoldás csak odafigyelés kérdése.
Tárhelypark.hu - Tárhely szolgáltatás
válaszok
a két kérdésre:
1. igen van, a boost modul valósít meg ilyen statikus cache dolgot.
2. igen, van, memcache modul.
illetve van még egy olyan dolog is amit úgy hívnak pressflow, ez tulajdonképpen egy karbantartott drupal core-hack csomag, direkt nagy terhelésű oldalak számára. például nagyon hasznos tulajdonsága a hagyományos 6.x core -al szemben, hogy névtelen látogatóknak nincs sessionje. és persze sok más finomság, rengeteg anyagot lehet róla fellelni.
-
clear: both;
Megprobalok en is hozzaszolni...
Minden elismeresem a szolgaltato fele, tetszik a hozzaallasuk!
1. Igen, mint az elottem hozzaszolo is megirta a Boost modul csinal ilyet, en meg halkan azert hozzatennem hogy tudtommal ez foleg (vagy kizarolag) azokat az oldalakat gyorsitja amiknel nincsennek belepett felhasznalok...
2. Igen. Viszont itt inkabb a szolgaltato szemszogebol lesznek gondok, pl. ki kap memcache-t es ki nem vagy csak erre a konkret egy oldalra lenne kivetelessen megengedve? Mekkora memoria lene kiosztva erre a celra... Stb. Futolag raneztem a konkret oldalra mivel mostmar megvan a cime is, en talan ugy erzem hogy ez itt folosleges lenne.
Szerintem ha az alap drupalban bekapcsolja a gyorstarazasokat es nagy idoket allit be (mint az elottem hozzaszolo is irta) attol fuggoen hogy a tartalmak milyen gyarkan valtoznak. Nekem az az erzesem hogy itt a tartalom szinte nem is valltozik a nodok tartalma egyszer megirodik es nem valtoznak csak esetleg ujak jonek letre ... Ha a felhasznalok nincsenek belepve es csak mint vendeg nezegetik az oldalt vagy jelentos reszuk ilyen akkor megneznem a boost modult hogy mekkora javulast hoz ... Ezeken felul ha ez nem eleg akkor megneznem magat az oldalt, a sminket, a dinamikussan generalt blokkokat hogy ott mit lehet tenni a kevesebb mysql lekerdezesek erdekeben.
Szerintem ennyinek elegnek kellene lenni.
Memcached
átnéztük felületesen a lehetőségeket, és ez a megoldás osztott tárhely környezetben igen sok problémát vet fel. Úgy biztonságit mint performanciát egyaránt. Jól látod a kérdést, hogyan korlátozzuk, hogy ki mennyi memóriát használhat, hogyan bontod külön a felhasználókat mikor egyetlen démon fut stb. De említhetném az árat vagy a monitorozást és hibakezelést is. Akkor már inkább Varnish...
Tárhelypark.hu - Tárhely szolgáltatás
92 normális
Nem ismerjük a webhelyet, de 92 lekérdezéstől Drupal körökben nem szoktak a szívükhöz kapni az emberek. :)
A gond ott van, hogy ha többségében nem belépett felhasználókról van szó, akik gyorstárból (cache_page tábla) kapják az oldalt, akkor az elvileg 1 db lekérdezés. Tehát vagy nem működik a gyorstárazás, vagy a belépett felhasználók által lekért, nem gyorstárazott oldalak indítanak el extrém sok lekérdezést.
Ezért szerintem Memcache és hasonlók helyett első körben a webhelyet kellene egy kicsit körbenézni, pl. modulok egyenkénti kikapcsolásával. Kezdve a kevésbé népszerű, egzotikusabb modulokkal. (Egy Views vagy egy CCK rendeltetésszerű használat mellett kevésbé kockázatos, mint egy zöldfülű által írt kismodul.)
Lehet-e a lekérdezési dömpinget időbeli eloszlás szerint vizsgálni? Pl. délután 2 és 3 között jött kismillió lekérdezés – pont akkor, amikor az adminok moozogtak a webhelyen.
Kérdezőnek: Drupal naplóban látsz-e valami furcsaságot? PHP hibák és hasonlók, beragadt cron…
Nem tudok egyetérteni a normálissal
Egy oldal megjelenítéséhez 92 lekérdezés semmi esetre sem mondható normálisnak véleményem szerint (ha ez aztán megy a cache-be, és legközelebb onnan jön, más a helyzet.)
Üzemeltetési oldalról:
Egy oldalt illene 2-3 sec alatt kiszolgálni a szervernek, tehát mysql futtatásra marad mondjuk 1 sec. Ez azt jelenti, hogy az adatbázisnak 92 query / sec-el kellene pörögnie egyetlen látogatóval. Persze itt is van cache, és ez időszakos, hiszen nem frissítgeti az oldalt folyamatosan az egy user. De tételezzünk fel pár ezer felhasználót mondjuk az esti órákra tömörülve. Így már kezd más lenni a kép, és hamar el is jutunk a több százezres lekérdezésszámig.
Programozói oldalról:
Feltenném az alap kérdéseket: miért is kell egy oldalra 92 lekérdezés? Mit jelenítünk meg ami ezt indokolja? Igazából semmi. Az esetek többségében (és itt általános tapasztalatokat írok, nem a konkrét példát) arról van szó, hogy az oldal tulajdonosa/programozója rosszul használ egyes komponenseket, vagy olyan nem tesztelt modulokat telepít, amik ezt okozzák (konkrét drupal példát nem tudok, de WP, Joomla stb. sorolhatnám). Amíg 50 látogató van az oldalon semmi nem tűnik fel, amikor ez megváltozik akkor meg érthetetlen, hogy az évek óta működő oldal miért is lassul be, és kell neki 5-6 processzormag.
Itt viszont egyetértek veled, el kell kezdeni a modulokat ki/be kapcsolgatni, és kitalálni mi okozza a hibát. De azért megjegyzem, ezt nem egy éles rendszeren kellene tenni! Lokális fejlesztői gép, debug, stb.
Egyik pontnál sem szabad elfelejteni, hogy hosting környezetről beszélünk, ahol egy olyan gépen futtatod az oldaladat, ahol mások is vannak, és azért fizeted a töredékét évente a szerver árának, mert a szolgáltató az oldalad mellet más oldalakat is futtat.
Tárhelypark.hu - Tárhely szolgáltatás
csak üres gyorstárnál
Ahogy írtam, megy a cache-be, és onnantól kezdve 1 lekérdezés. Nem belépett felhasználók kapnak nem betárazott oldalt, de ott is több kisebb oldal-komponenst betáraz a rendszer, és a következő lekérésnél már jelentős részben azokból építkezik. Nézd meg menyi ilyen-olyan cache_ tábla van az adatbázisban. 92 lekérdezés/oldal akkor fordulhat elő, ha teljesen üres a gyorstár.
Teljesen igazad van, hogy nem éles környezetben kellene az ilyen problémáknak kijönnie, de sajnos ezt elég nehéz a megrendelőkkel elfogadtatni. Ő annyit lát, hogy kész az oldal, színes, szagos, és nem érti, miért kellene még tesztelésre, hangolásra, optimalizálásra költeni. Sokszor arról nehéz meggyőzni az átlag megrendelőt, hogy webáruházat, komolyabb webhelyet ne 500-1000 Ft/hó alsó kategóriás osztott tárhelyen próbáljunk futtatni, mert előbb-utóbb nagyon ráfizetünk.
Igen
En ugy mondanam hogy van "profi" munka ahol megvan hogy mit miert es van egy "amator vagy olcso kategorias" munka vagy hozzaallas. Nem erre az oldalra meg szolgatatora gondolok most hanem altalaban! Nem szeretnek senkit sem megserteni!
Altalaban az szokott lenni hogy valaki oszetakol egy oldalt ami kinezesre szep es jo, az oldalnak van keresve egy minnel olcsobb tarhely ahol az szepen megvan. Rengeteg olyan oldal van aminke szinte allig van latogatoja, idonket valaki megnezi a tulaj es a keszitokon kivul. Neha par keresorobot is megnezi. Az hogy mi mennyire van jol es optimalissan megcsinalva az addig nem is jon elo amig ilyen keves a latogato.
A tomeg viszont ehhez akar hasonlitani egy nagyobb folrgalmu helyet is vagy egy komolyabban elkeszitett munkat is. Ott csak az van hogy amaz ennyiert is megcsinalta, vagy hogy amaz olyan tarhelyen is elfer.
Ebben az esetban is nagyon hasonlo a helyezet, sok a latogato es igy mar eszreveheton nagyobb a terheles a szerverre. Ilyenkor mindket oldalrol elojonnek a gondok. Tetszik a szolgaltato hozzaallasa (gondolom meg kezdok ilyen teren) ugyerzem nem voltak tisztaban hogy a drupal mennyi sql lekerdezest general, de pozitivan allnak a dologhoz, ugyerzem korektul szeretnenek megoldast talani.
A masik oldalrol is latok hajlamot a gond megoldasara, itt azert nagyobb gondolkat latok, ugyerzem volna itt meg tanulni ezt azt ... Erdemes lenne kicsit elmenyedni a html dolgodkan, itt pl. az oldal felepiteser gondolok html, head, body stb. Tisztaban kell lenni azzal is hogy ha minden letezo es nemletezo dologgal telepakolunk egy oldalt akkor annak nagyobb lessz a terhellese a szerverrre is. Lassabban is toltodik be a latogatonal.
Tetszik a szolgaltato hozzaallasa (gondolom meg kezdok ilyen ter
8 éve hostolunk, 10 éve fejlesztünk nagyvállalati szoftvereket (bankok, pénzintézetek, biztosítók), köztük igen nagy látogatószámú oldalakat, facebook, hírportál, banki sms rendszer, tőzsde, termelésirányítás stb.
Több ezer oldalt üzemeltetünk, és még több domain-t regisztrálunk.
Szeretjük amit csinálunk. Az, hogy segítünk pont az ellenkezőjét jelenti...
Tárhelypark.hu - Tárhely szolgáltatás
Ertem en, a szamok szepek, de
Ertem en a szamok szepek, de akkor meg miert kellett elcsodalkozni a Drupalon? nekem nagyon az jott le hogy a memcache-rol sem sok foglamuk van ...Gondolom azt a sok bonyolult oldalat sem oldalankent egy egy sql lekerdezessel oldottak meg...
Az teny hogy egy nagy ceg nem nagyon fog folgalakozni egy olyen gondal mint ez, azert is irtam hogy tetszik a hozzaallas, ok egyszeruen annyit mondanank hogy atlepte a hatarokat az oldal es vagy optimizaljon vagy valaszon masik csomagot vagy viszlat. Gondolom nem eri meg nekik ember -ora alapaon annyi penzert egy ilyen ugyel foglalkozni ...
Nagy cég
Nem mondtam, hogy nagy cég, csak régóta csináljuk :) Köszönöm, örülök, hogy érthető amit írok, reméltem, hogy nem értitek félre
Tárhelypark.hu - Tárhely szolgáltatás
2-3 masodperc ennel az oldalnal szerintem sok
2-3 masodperc ennel az oldalnal szerintem sok, amikor megnyitom az oldalt nekem lassan toltodik be. Persze lehet azert hogy nem magyarorszagon vagyok, vagy az oldal "felepitese" rossz vagy a szolgaltato a hibas vagy ezek mind oszesen. De azert en ugy erzem hogy ha errol az oldalrol beszelunk (en megneztem az oldalt, gondolom a szolgatato is ugyszinten) akkor azert nekem ne mondja azt hogy 2-3 masodperc jo. Szerintem ez lassan toltodik be. Az hogy miert az mas teszta.
Egy Drupal oldalt meg teljesen ertelmetlen oszehasonlitani egy kozonseges nem Drupal oldallal. Ha ugynezzuk akkor ezt meglehet csinalni egyetlen SQL lekerdezes nekul is tisztan statikus html es php oldalakkal.
Igazat adok Edit-nek kb. 100 sql lekerdezes nem a vilagvege. Jol belott szerveren azt a lekerdezes mennyiseget a mysql cachebol kiszolgalhatja tekintettel hogy nem nagy az adatok mennyisege sem es gondolom elegge ugyanazok a lekeresek mennek az sql szerver fele...
A Drupal vagy az Apache logjaban vannak-e olyan bejegyzesek hogy ilyen vagy olyan fajlt nem talat meg a szerver? Konkret pelda erre a favicon.ico ez itt nincsen meg. Amikor a bongeszo ezt lekerdezi (es leszokta kerdezni) akkor a Drupal az egesz oldalt adja helyette feleslegesen... Szoval a hianyzo fajlokat meg kell oldani
Meg mindeg azt sem tudjuk hogy hany user van az user tablaban az is lehet hogy csak par. Akkor viszont kimondhato hogy nem belepett userek generaljak a forgalmat. Innentol akkor mar csak az a kerdes hogy gyorstarazza-e az oldalakat es ha nem akkor miert?
U.I.: ez a fajl is hianyzik /sites/all/themes/theme582/images/bg-searchform.png
Csak a favico-ra szeretnek
Csak a favico-ra szeretnek reagalni. D7 alatt a settings.php-ben lehet konfigolni, hogy milyen tipusu fajlokra menjen ki egy statikus html kod a teljes drupal_not_found helyett. Ezt a settings.php-ben a "Fast 404 pages" kifejezesre keresve lehet megtalalni. Alapertelmezes szerint a nepszeru statikus fajlok kiterjesztesere (png, ico, jpg, etc) van matcheles.
De egyeb sebessegnovelo intezkedesek is vannak a settings.php-ben erdemes atolvasni az egesz fajlt.
--
()=() Ki oda vagyik, ('Y') hol szall a galamb C . C elszalasztja a ()_() kincset itt alant.- Az említett oldal
Gondold végig: címlapodon van 5-10 tartalom, 5 menü. Ezeknél mindnél lekérdezi a rendszer, van-e az aktuális látogatónak hozzáférése, milyen (access, edit, stb).
A képek, fájlok nem egy táblában vannak a node-okkal. Mindegyik verziókezelt (lehet) erre is ránéz, melyik a legfrisebb verzió… stb-stb.
Több tartalomtípusod lehet, mindegyik külön tábla, más csatold mezők…
Míg egy „pistike” rendszernél ilyen nincs. Van egy admin juzer (jó esetben .htaccess-al védett oldalakat ér csak el), meg a többi, aki az oldalt nézi mind látogató. Ezeken a helyenek általában 1 táblában van minden megoldva.
Sztem, nem kell a rizsa, hogy más mennyit használ, mert baromira nem összehasonlíthatóak az oldalak. Ha lassú az oldal, akkor cache kell, meg gyors sql. :)
Kapcsold be a devel sql logot, és látod, milyen lekérések futnak, hányszor.
--
Szabó Dénes - Internode.hu - Munkára fogott weblapok
Na külön írom, mert egyébként
Na külön írom, mert egyébként kicsit összeugrik a szál.
Illetve elkezdtem ide írni, 'aszt blogposzt lett belőle: http://szantogabor.com/hirek/lekerdezesek-es-cache-a-drupalban-mennyi-az...
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Nagyon örülök, hogy sikerült
Nagyon örülök, hogy sikerült egy komoly vitát elindítanom a témámmal. Nagyából tudom, hogy egy amatőr munkája is az oldal, de az első oldalaimhoz képest nagyot fejlődtem :)
Elvileg javítottam a hiányzó fileokat is.
Az a kérdésem, hogy a 3-4 sec várakozás az mi lehet? Biztos, hogy minden esetben az adatbázis? Ugyanis, ha az oldalon vagyok már, akkor ezt a lassulást nem tapasztalom.
van egy ilyen network fül
https://skitch.com/aboros/g6m8a/adatbazis-teljesitmeny-optimalizalasa-dr...
-
clear: both;
ez pl nemtom micsoda
de vársz rá 0.6nál is többet. meg a green caller vagy mire szintén vársz 0.3at, az már 1 sec. jobban nem néztem szét.
https://skitch.com/aboros/g6mef/welcome-to-cbs-central-european-internat...
persze ez nem a szerver oldalon keletkező várakozás, hanem a külső oldalra vár a böngészőm. szóval ez az emlegetett "sok a lekérdezés" dolggal nem kapcsolatos :)
-
clear: both;
Javult mar ...
Javult mar de mint maganban is irtam es most irtad itt hogy a hianyzo fajlokat javitottad, a favicon.ico meg mindeg hianyzik...Ahogy most ujbol futolag ranztem az oldalra mostmar eleg gyorsan legeneralodik maga a html fajlod inkabb mostmar a tobbivel van baj ... A szolgaltato meg esetleg megirja hogy most mi a helyzet mysql teren ha meg koveti ezt itt.
A tobbi optimalizasahoz talan erdemes lenne egy uj temat nyitni mert ez mar nem az adatbazis teljesitmenyerol szol hogy ezt a temat ne szemetejuk azzal is tele. Szerintem annak mar inkabb uj tema kellene.
Utoirat: Most igy koran reggel (hajnalban) ahogy nezegetem az elobb azt irta hogy 1 latogato van most meg egy sem es tovabb nezegetem, ebbol arra kovetkeztetek hogy a belepett felhasznalokat irja ki vagyis volt 1 belepett meg azt nem tudjuk hanyan nezik csak ugy mint en. Szoval most a bongeszo mar eleg turhetoen nyitja az oldalakt. Gondolom azert rajtam kivul nem sokan nezegetik :) A szolgatato majd megnezi hogy terheleskor mekkora a "baj". Reszemrol mint irtam is most igy ok. Ami a kinezesit illeti hogy megsem nyissunk uj topicot csak annyit fuzok hozza hogy engen zavarni szokott az az alavult bongeszore valo figyelmeztetes. Tudom hogy az van. De legalabb csak a fooldalon lenne ott vagy leokezhatnam es tobbet ne szoljon ... Kicsit meglepodtem amikor az ingyenhivo hirtelen megszolalt a csendben :) De azota legalabb halgat. Az oldal alljan azok a sok szamlalok vagy statisztiaka vagy miacsudak nekem olyan "gyerekesek" en csak azt a 4 matrixot hagynam ott meg azt az egyet abi ezektol jobbra van. Analitikanak eleg a google is szerintem. Elgondolkoznak ha sok a belepett uszer es az miatt is nagyobb a terhelesed a kelletenel, akkor mivel irtad hogy most ugyanaz kapja a sima odatevedt latogato meg a belepett is, hogy eltuntettnem a regisztraciot mert felesleges. Ha korlevelek miatt kell emailcim akkor azt maskepp is meglehet oldani, eleg lenne egy "ertesitest kerek form".
Kitiltottak a hostingomról a Drupal miatt....
Szia,
a favicon egyszerűen nem tudtam feltenni. (hiába címzem meg, akkor sem találja)...
Egy másik oldalamat is elkezdtem frissíteni és ezt már nem bírta kívárni a szolgáltató és kitiltott a siteról.
Fogalmam sincs, hogy mi az a hihetetlen túlterhelés, amit okoz az oldalam. Igaz van elég nézettsége, de szerintem ezt kellene bírnia a szolgáltatóknak.
Így most egy erős vassal rendelkező szolgáltatót keresek éppen :)
Erős vas?
Elég szépen leírtam mi volt a gond:
1. A tegnapi napon 1.200.000 lekérdezést futtatott az oldalad 1500 látogatóval
2. Bekapcsoltál valamit 18 óra körül ami meg folyamatosan insert-ált. 4 óra alatt sikerül 550.000 insert-et futtatnod.
Erős szerver, ezen vagy most: 8 processzormag 3.6 Ghz 32 Gb RAM, 5 TB Raid10. MySQL-nek 2 Gb cache memória, table cache: 64.000
Írtam neked, hogy adj admin hozzáférést, hogy átnézzük a beállításaid, nem adtál. E helyett elkezdtél valamit telepíteni, és megegyezésünkkel ellentétben nem telepítettél cache-t, csak amikor ma már kritikus volt a helyzet írtad, hogy "épp most akartam telepíteni"
Úgy gondolom mindenre nyitottak vagyunk, arra azonban nem, hogy miattad veszítsünk más megrendelőket.
Kipróbálhatod VPS-en is az oldalad, 1 hétig ingyen odaadjuk neked, az viszont nem ez az árkategória.
Tárhelypark.hu - Tárhely szolgáltatás
En nem frisittettem volna, amig emezzel bajok vannak
En nem frisittettem volna, amig emezzel bajok vannak, plane hogy valahogy erzni lehetett a szamok alapjan amit a szolgaltato irt hogy gaz lessz. Vagy ha igen akkor elotte megprobaltam volna kitalani hogy mekkora lessz a terhelles ...Az oldalt nem tudom milyen amit frissitettel, azt sem tudom hogy mit frissitettel rajta. Egyszeruen a szolgaltatonak elhiszem a szamokat, feltetelezem hogy az is Drupal, es gondolom kb. a zis ilyen jol van oszerakva mint ez amirol itt irkalunk. Szoval en nagyon nagyon ovatos lettem volna. Masreszt ha te belepsz az oldalra mint admin akkor az egybol nagyobb terhelest is jelent mint egy nem belepett mezei latogato.
Mi volt az, mit csinaltal amikor a terhelles megugrott, amit a szolgaltato irt?
A frissítés alatt elsősorban
A frissítés alatt elsősorban tartami, tartalom szerkezeti frissítést értek... (másik site)
Ami ami miatt talán megugrott a terhelés a redirect vagy a globaldirect modul lehetett, de azonnal javítottam a hibát. Az oldalam folyamatos gyorsítás (Drupal cache alatt üzemelt)
Döntöttem a szolgáltatóval kapcsolatban, tovább nem érdeklenek.
Találtam egy németországit jónak találom, csak nem tudom, hogy jó lesz-e (stabil, gyors).
Szeretném kérni a Te tanácsodat is. Köszönöm!
http://drupal.hu/forum/server-csere/15436
Üdv.
KALMI
tartalom szerkezeti frissítést értek...?
tartalom szerkezeti frissítést értek...? Miert nem localban fejlesztesz? Amikor mar minden szepen mukodik akkor rakod a production szerverre?
Nem biztos hogy egy masik szolgaltatonal jobb lessz a helyzeted, a gondok forrasat kell kikuszobolni. Raadasul akarhogy is nezzuk az en szememben ez a mostani szolgaltato nagyon korrektnek tunt. Persze ezt annak alapjan irom amit itt a forumon tapasztalok, de nekem korrektek...
Na meg ha az a frisites annyira nelkulozhetetlen volt akkor viszont konzultaltam volna a szolgaltatoval hogy mikor a legkevesbe terhelt a szerver, mongyuk hajnal 3-kor es akkor csinaltam volna es orultek volna ok is meg te is ... Hidd el ez aprosagnak tunik de nem az. Delutan 18 korul gondolom emegy is volt terheles a szerveren.
Több helyről dolgozunk,
Több helyről dolgozunk, dolgoztunk, ezért csináltuk így, illetve nem nagy javítgatások voltak...(elvileg erről is szólna a Drupal)
Mindegy döntöttem váltok... Szerintem egy ilyen site (sitok)-nak nem szabadna ennyire a servereket leterhelniük... Ezt laikusként (lelkes amatőrként) gondolom...
"Szerintem egy ilyen site
"Szerintem egy ilyen site (sitok)-nak nem szabadna ennyire a servereket leterhelniük"
Nanee. Iszonyat könnyű ám drupalban laikusként (lelkes amatőrként) olyan siteot összehozni, amit egy shared hosting ilyen leterheltségnél nem tűr meg. Tök érthető okokból. Pl felteszed a fb modult, és pikkpakk háromszorosára nő az oldagenerálási időd még bekapcsolt cachenél is.
Szóval tény és való, hogy drupallal bárki össze tud rakni egy weboldalt, de bizonyos elvárások felett a "bárki" már bizony kevés.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Mik az elvárások?
Persze, ha nem használok cache-t (megértettem azonnal be is kapcsoltam minden siteon), de mint említettem használok....
Ok mik az elvárások? Vissza kérdezek, miért fejlesztenek olyan modulokat amik összedöntik a servereket? Nézegetem a Drupal oldalakat, modulokat, de szerintem az én oldalamnál vannak lényegesebben összetettebb sitok, amik feltételezem a drupal.org modulokból lettek összeállítva és mégis működnek....(megjegyzem, ha kész modult telepítek egy elképzelés szerint nem hiszem, hogy egy profi is a pipa és install parancsnál többet csinál, ha minden modul szuperul működik)
U.I.
Az amatőrségemet inkább a hobbinak fogom fel, mint például vannak profi kőművesek, meg ácsok, stb. ,de sokan saját maguk építik fel a házukat..., ami van ilyen komplikált, mint egy Drupal oldal (a legelső oldalam se ilyen volt még).
Azonkivul hogy elolvasod meg is ierted hogy ki mit ir neked?
Azonkivul hogy elolvasod meg is ierted hogy ki mit ir neked? Az elottem hozzaszolo is szepen megirta neked. Mi nem ertheto ezen? (Picit mar kezdem unni...)
Ugyerzed hogy akik a modulokat irjak azok azert csinaljak hogy osszedoncsek a szervert? Egyszer mar megirtam ha jol remlik hogy sok helyen elo sem jon a gond mert az oldalnak van napi par vag ypartiz latogatoja. Ott teljesen mindegy hogy egy oldal lekeres 1 vagy 200 mysql lekerdezes general. De ha van 2000 latogato akkor ott a 2000 (ketezer) vagy 200000 (ketszazezer) nemmindegy. Szorozzuk be ezt meg azzal hogy egy oszott tarhelyen van 5 ilyen oldal akkor meg meg nagyobb a kulonbseg.
Hazepites...? Nezd ugy hogy egy kutyahazhoz ugyerzem eleg amator tudasom van de emeleteshaznak mar nem merek nekifogni. Erre most meg jon az is hogy nem baj majd a cementet (pl. VPS) is majd en amatoren megcsinalom, meg azt sem veszek, minek az ...
Egy masik pelda, az utobbi idoben ketten is megkerestek innen a forumrol hogy dolgozzak be nekik, nagyvonalakban a valaszban a lenyeg az volt hogy nem erzem magam profinak hogy elvallajam ...Szoval tudni kell hol a hatar...
Nincs szuperinteligens rendszer
„Vissza kérdezek, miért fejlesztenek olyan modulokat amik összedöntik a servereket? ”
Már ne is haragudj, de ha Te zuhanyzás közben szárítod a hajad és megcsap az áram az sem a hajszárító gyártójának, sem a zuhany készítőjének, de még a kőműveseknek, no meg a ház tervezőjének se róhatod fel.
„(megjegyzem, ha kész modult telepítek egy elképzelés szerint nem hiszem, hogy egy profi is a pipa és install parancsnál többet csinál, ha minden modul szuperul működik)”
Mondjuk legalább a README.txt-t el szokta olvasni egy „profi”. No meg mielőtt bekapcsolja egy rendszeren az adott modult, egy tesztrendszeren kipróbálja. Jó mondjuk ez utóbbit tényleg csak a nagyon profik szokták megtenni.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
Nem akarok vitatkozni veled, de ...
Nem akarok vitatkozni veled, de van egy production (ami uzemel ezt lassak a latogatok) es van egy amin fejlesztesz, jobb helyeken van megegy testing is azon meg teszteled az egeszet. Az teljesen mas teszta hogy tobb helyrol fejlesztitek attol meg otthon is lehet egy szerver meg dinamikus ip -vel is megoldhato.
Nem akarlak sem lebeszelni sem rabeszelni de jol gondold at az egeszet. Egy russzul oszeallitott oldallal ha van kello latogato azert szep komoly vasakat is padlora lehet kuldeni... Szinten nem akarom sem biralni sem vedeni a szolgaltatot de a hozzaallasuk jo (Dicseret erte!), a nemet szerveren ezt a hozzaallast tuti nem kapod meg, ok biztos nem fognak ide jonni a gondjaiddal. Megvannak a keretek es ha lassu lessz az oldalad akkor esetleg anyit mondanak hogy naluk minden ok a tobbi gond meg nalad van. Es nem ezert vagy azert, egyszeruen nem az o dolguk.
Miert nem probalod ki a VPS-t amit a mostani szolgaltatod kinal? Persze osztott tarhely meg VPS valoban nem ugyanaz az arkategoria.
szerintem nekik van igazuk
A szolgáltató nagyon korrekt. Itt neked kellene utána nézni, mi volt az a félmillió insert. Fut valami elszabadult modul vagy szkript a webhelyeden, ennek a kilövése a te dolgod, nem az övék. Az adatok alapján teljesen jogosnak tűnik a lekapcsolás.
Ki lett lőve a modul azonnal
Ki lett lőve a modul azonnal (kb 3 precig futott a rossz modul a többi nem én voltam), mint írtam (mellesleg csak ezt az egy modult tettem fel, addig csak tartalom beküldés volt, illetve nyelv frissítés ennyi) 3630 oldal letöltés volt az összes oldalon, illetve 1200 látogató.
Olyan gond nem lehet, hogy a szolgáltató lassítja az oldalt és a Drupal pedig folyamatosan próbálkozik a letöltéssel? Pl: rendszeresen veszítette el a kapcsolatot mikor modul frissítés ellenőrzést vagy nyelv frissítés ellenőrzést végztem?
tesztoldal?
Ezek szerint te az éles oldalon kísérletezel?
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Tesztoldal!
Nagyon jó a kérdés, és a válasz: igen, az éles oldalon kísérletezik, ami több szempontból is rossz, és sajnos napi rendszerességgel fordul elő más oldalaknál is.
1. Rossz a szolgáltatónak, azaz nekünk, mert hibás szkriptek, beragadt redirect-ek pillanatok alatt borítják a szervert. Van ellenszer természetesen, de nem túl felhasználóbarát, és fikázó posztok lesznek belőle, hogy szolgáltató így meg úgy kill-el meg limitál.
2. Rossz az oldal látogatóinak és szerintem igen nagy presztízs veszteség amikor a potenciális vevő azt látja az oldalon, hogy PHP Warning, meg notice, esetleg Internal 501... Az elvesztett ügyfeleken keletkezett veszteség kisebb oldalnál is összevethető egy saját VPS pár ezres árával, vagy egy saját Virtualbox-os környezet telepítési költségeivel (idejével).
3. És nem utolsó sorban rossz az oldal tulajdonosának is, mert az éles környezetben nem ritkán ki vannak kapcsolva olyan figyelmeztetések pl. security okok miatt, amikből látható lenne mi is a a hiba. Így legtöbb esetben meg kell elégedniük a "nem megy" jelenséggel, amivel aztán kereshetik a szolgáltatót.
Megoldás:
Mi ebből a fórumból sokat tanultunk (ez úton is köszönöm az elindítónak, aki mint írta is, már nem ügyfelünk) és próbáljuk levonni a megfelelő következtetéseket. Ebből az elmúlt hetekben az az ötletünk nőtt ki, hogy ügyfeleinknek fejlesztői környezetet biztosítunk a jövőben külön szerveren, aminek infrastruktúrája megegyezik az éles környezettel (cpanel, ftp, drupal telepítő stb.), de csak egy felhasználó lesz rajta egy időben. Minden log fájl elérhető, és még a szerver statisztikákra is rá lehetne nézni. Így mindenki tesztelhet, fejleszthet és megoldhatja a problémákat.
Tárhelypark.hu - Tárhely szolgáltatás
Nekem mindenesetre tetszik
Nekem mindenesetre tetszik a szolgaltato hozzaallasa. Ritka egy eset hogy ennyire probal segiteni. Nagy plussz erte. Csak dicserni tudom.
A volt ugyfel (sajnalom hogy elveszitettek) is remelem tanult ezt azt innen, es a masik szolgaltatonal mar kevesebb gondja lessz.
Egyreszt jo otletnek tartom a fejlesztoi kornyezetet, de az en szememben picit felesleges. Persze ha van ra vevo akkor miert is ne csinalnak.
En szemelyesen kicsit ugy erzem hogy mindenkinek tudni kell, nagyjabol, hol a tudasanak hatara es milyen munkat vallalhat el es mit inkabb ne... Masreszt ha nem tud salyat maganak ottohn oszerakni egy fejlesztoi kornyezetet ahol fejlesztget akkor azert nagyobb kaliberu munkakat ne vallaljon el mert elobb utobb gondjai lesznek vele...Es olyankor mindharom fel joggal panaszkodik...
példás hozzáállás
Példás hozzáállás, nem csalódtam benned!
A témánál maradva talán hasznos lesz a link, hiszen írtam már erről régebben: Teljes értékű Drupal fejlesztőkörnyezet kialakítása Ubuntu Linux rendszeren
Ui.: Ha nem baj, a hozzászólásodat linkelem az aláírásomban, mivel remekül összefoglaltad a tesztoldal szükségességét. Arról nem is beszélve, hogy mennyire megkönnyíti a fejlesztést. Külön pont, hogy a szolgáltató szemszögéből mutattál rá dolgokra, pedig ebbe így sokan nem gondolnak bele.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Volt ügyfélként nem kommentelem...
Volt ügyfélként nem kommentelem, mi mint szolgáltató cég, az ügyfeleinkkel nem bánhatnánk így (nem szúrom be a kapott levelet és nem pazarlok az ügyre több energiát), és el akarom felejteni az egészet (le akarom zárni a fórumot is).
Pozitív oldal:
A Másik szolgáltatónál érdekes módon pik-pak megy minden :-(. Szóval....Lehet béna vagyok, de.... Szerencsére találtam egy olyan szolgáltatót, aki az én igényeimet is kit tudja elégíteni, és egy pillanatra se esik le a sebesség, teljesítmény...Érdekes....
Köszönöm a Fórumozók segítségét is nagyon sokat segítettek a témában!
KALMI
Éles oldal nem tesztoldal…
Amíg be nem kapcsolsz ott is az éles oldalon valami olyan modult, amit előtte nem próbáltál ki tesztkörnyezeten. Tudom, hogy miről beszélek, személyes tapasztalat. Nem azt mondom, hogy te vagy az oka mindennek, de ha az oldalak felén nekiállnak így kísérletezni, annak könnyen lehet csúnya vége.
Személyes véleményként csak annyit tudok hozzátenni, hogy nekem már volt dolgom Viktorral, végig nagyon korrekt és segítőkész volt. Az itteni hozzászólásait elolvasva semmit sem csorbult ez a kép, még ha esetleg egy adott helyzetben ingerültebben reagált feléd… próbáld megmagyarázni pl. 18 ügyfélnek, hogy 2 másik kísérletező kedve miatt lassú az oldaluk.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Rendszergazdakent es
Rendszergazdakent es fejlesztokent is csak tamogatni tudom az itt elhangzottakat. Nem szabad osztott tarhelyen fejleszteni. Ezt nem tudom jobban kiemelni, mert akkor ledorongolnak, hogy szetverem az oldal szep dizajnjat.
Nem tudom elhinni, hogy nem tud a cegetek venni egy kozepesen jo gepet (C2D mar bosegesen eleg), es felhuzni vagy felhuzatni ra egy hosting kornyezetet. Ha a hozzaertes hianyzik, vannak emberek, akik orommel vallalnak olcson ilyesmit, es hosszu tavon megeri befektetni.
Most azert jo nektek a nemet oldal, mert nem csinaltok semmit vele, de az elso hasonlo stilusu fejlesztesnel a nemetek egyszeruen bekorlatozzak az oldalt es hello, rosszabb esetben suspendelik a hozzaferest, es akkor meg inkabb hello. Ok egyaltalan nem lesznek cizellaltak, mert nem erdekuk. A magyar szolgaltatok azert cizellaltabbak, mert sajnos itthon eleg sok olyan oldal van, amit egyszer megirtak, es azota semmilyen tamogatas nincs hozza, igy ha azokat nem tamogatnak meg, akkor nagyon sok penzt veszitenenek.
Szoval, kerlek titeket, tegyetek rendet a fejekben, ha ehhez a fonok, manager, igazgato, akarkicsoda beleegyezese kell, akkor beszeljetek vele, es probaljatok megoldast talalni, nem tudom elhinni, hogy nem lehet ezt a problemat kulturaltan megoldani.
Nem a hosting szolgaltatok a szemetek, hanem egyszeruen arrol van szo, hogy ok nem tudnak az egyes ugyfelekre tekintettel lenni, nekik egyszerre kell nagyon sok ugyfelnek megfelelni. Egy shared hostingnal mindig az a gond, hogy van egy darab gep N darab ugyfelnek (N>200 ez biztos). Nem lehet buntetlenul novelgetni az eroforrasokat, mert ez tulajdonkeppen csak az aranyokkal valo jatszadozas, annak az egy gepnek ugyanugy vegesek lesznek az eroforrasai, mint igy.
--
()=() Ki oda vagyik, ('Y') hol szall a galamb C . C elszalasztja a ()_() kincset itt alant.