rendszergazda
Azért bátorkodtam belinkelni a hozzászólást, mert több nagy webhelyen is azt tapasztaltam, hogy nagy méretű (~500.000 - 1.000.000 rekord) search* táblák lehalnak InnoDB-vel. Ha ilyenkor váltok MyISAM-ra, akkor még kb. 50%-kal lehet növelni a táblaméretet. Jellemzően ez olyan webhelyeken jön elő, ahol nagy mennyiségű tartalom van, folyamatosan töltenek fel, viszont ritkán használják a látogatók a keresőt.
Egyébként minden ilyen webhelyemen a MyISAM is csak átmeneti megoldás volt, és előbb-utóbb le kellett kapcsolni a beépített keresőt (helyette javás megoldások, vagy Google Site Search).
D7-ben már alapértelmezett az InnoDB.
Ezek bonyolult elemzést igénylő kérdések, csak arra akartam felhívni a figyelmet, hogy nem lehet ennyi információ alapján egybites válaszokat adni, hogy mitől lassú egy webhely. Van úgy, hogy egyetlen lekérdezés miatt, és aztán annak az egy lekérdezésnek az optimalizálása alá kell rendelni mindent (szélsőséges példa). Itt még azt sem derült ki, hogy valójában teljesítmény vagy skálázási probléma van-e, stb.
Első körben természetesen meg kell csinálni, amit a rendszergazda kért.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Kiegészítés
Ha ez számít valamit akkor nálam egy Devilboxban fut a Drupal. Azért Devilboxban mert csak ezzel tudtam olyan működőképes localhost szerverkonfigurációt előállítani ami hasonlít a távoli szerver összeállításával és könnyű módosítani az összetevőket. Sajnos a Drush nincs a Devilbox előretelepített vagy az engedélyezéssel beállítható programjai között. Hagyományos telepítéssel mindig hibák jöttek elő mert a telepítési leírások nem egyeztek a rendszerem (Ubuntu 2204.2 LTS) telepítési parancsokra adott reakcióival. Akkor megpróbáltam módosításokat, majd hibákat javítani ami egyre több hibát eredményezett és befulladt a szerver telepítése. Korábban nem használtam Drush-t, de úgy előbb utóbb hibák kezdenek előjönni a frissítések után amit nem is mindig vettem észre csak hónapok múlva. Úgy láttam, hogy a Drush jobban kezeli a frissítéseket mint a kézi frissítés. Most úgy gondolom, hogy Drush nélkül nem érdemes a Drupallal foglalkozni ha valami stabil fejlesztést szeretnék. Most leálltam, mert kifogytam az ötletekből és a neten sem találok már semmi használhatót amit még ne próbáltam volna. 12 éve használok Drupalt, de most mintha kiértem volna a lehetőségeken.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Úgy gondolod, hogy a problémát a Devilbox okozza?
Úgy gondolod, hogy a problémát a Devilbox okozza?
Szerintem vagy a Composer másolja rossz helyre a Drusht vagy a Drush launcher keresi rossz helyen. Nem tudom, hol kellene lennie a Drushnak a projectben vagy hol lehet beállítani, hogy a Drush launcher hol keresse?
Köszönöm az ajánlatod a Landora. Majd egyszer kipróbálom, de tartok tőle, hogy nem menne zökkenőmentesen a Devilbox mellett. Biztosan lennének olyan beállítások amelyeket a Devilbox végzett el és az uninstallálása után is megmaradna és a Landóval ez hibához vezethet. Gondolom, így az egészet egy Ubuntu újratelepítéssel kellene kezdeni és erre most nem állok készen. (Persze csak a sok hasonló rossz tapasztalat alapján mondom)
Ránéztem a Lando telepítésére, ami úgy kezdődik, hogy távolítsam el a régi Dockert és Docker Compose-t. Na itt kezdődnek a problémák. A Devilbox ettől rögtön harakirit követne el és többé soha nem lehetne beüzemelni a Landó pedig a Devilbox miatt nem indulna. Két szék közül a pad alá. Tapasztalatból tudom, hogy a keletkező hibák javítására felesleges egy hetet pazarolni. Legegyszerűbb és gyorsabb ilyenkor a rendszer újratelepítése.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
„[…] ha adott modulokat
„[…] ha adott modulokat lehetne pénzzel támogatni”
Ami az anyagi támogatást/motivációt illeti, többféle módját is keresik és/vagy már használják is páran. Amíg a Drupal Association nem dolgoz ki központilag biztosított funkciót a Drupal.org-on, addig a jelenlegi körkép valóban kissé vegyes:
Páran (pl. a Webform és LDAP modulok, a FarmOS Drupal-disztribúció vagy a Simplytest.me tesztfelület) az Open Collective platformot használják.
Vannak (pl. Pekker Bálint vagy Dmitry Porokhnya), akik a gyorsabb, egyszerűbb adakozást elősegítő Buy Me a Coffee-n regisztrálták magukat.
Akad példa arra is, hogy valaki a Composer csomagkezelő által biztosított csatornán keresztül kommunikálja, hogyan lehet őt támogatni az ügy érdekében:
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A gond a felhasználókkal van
No, akkor válaszolok magamnak, bár kicsit érdekes:
www.xxx.hu-t xxx user tudja adminisztrálni, infopont.xxx.hu-t infopont user.
xxx user egy valós ftp felhasználó, aki fel tud tölteni a www.xxx.hu alá, illetve infopont.xxx.hu alá is.
A szerver egy Suse lehet véleményem szerint, a következő lehet a könyvtárszerkezet:
|-httpdocs | |-httpsdocs | |-subdomains | |-infopont | |-httpdocs
A www.xxx.hu a gyökérbe telepített könyvtárból fut, az infopont.xxx.hu a subdomains/infopont/httpdocs-ból (sajnos ez van, nem tudtam megoldani a több oldal egy drupal kódbázison problémát).
A subdomains/infopont/httpdocs tulajdonosa is az xxx felhasználó volt, illetve nem volt infopont user, emiatt nem működött a könyvtár létrehozás illetve jöttek a hibaüzenetek.
Létrehozva a hosting adminisztrációs szoftverével az infopont felhasználót, az említett könyvtár tulajdonosa egyből ő lett, és eltüntek a hibaüzenetek.
Bár ez számomra elég rejtélyesnek tűnik, de mindegy, probléma megoldva.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Telepítés
Sziasztok!
Most fogok hozzá egy teszt telepítésnek:
- Az alap:
- Fizetős web szolgáltató
- Apache/1.3.37 (Unix)
- PHP Version 5.2.1
- MySQL 5.0.27
- Drupal 5.1
- A letöltés:
- Kicsomagolás, FTP upload:
- A modul: modules/tinymce
- TinyMCE: modules/tinymce/tinymce
- Adminisztráció> ...
- modulok > Engedélyezett: TinyMCE 5.x-1.x-dev
- Felhasználó kezelés > Hozzáférés szabályozás
- Webhely beállítása ? TinyMCE > Add new TinyMCE profile
Fontos: be legyen állítva mindkettő az authenticated user részére, mert különben nem jelenik meg. (access + administer tinymce)
Itt is be kell jelölni a hozzáférést.
(/modules helyett /sites/all/modules is tökéletes jó, tested)
Ezeken éppen most mentem végig csont nélkül, tehát a telepítő működőképes adott körülmények között.
Ha ez mégsem sikerül, akkor a szerveroldalon van a gond, küldj hibaüzeneteket.
- Az installkor a tábla létrehozása milyen hibát adott?
- Azt csak gyanítom, hogy kezdetben nem csak használatra kell a jog az authenticated felhasználónak, de utánna visszavonható.
Mindenkinek sikeres telepítést!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
miben kellene profinak lenni itt?
A szervert nem mi üzemeltetjük (sem PP, sem én). A Wish fiúk a körülményekhez képest jól helytálltak. A körülmények most ilyenek, következtetést maguktól is le tudnak vonni, és talán nem árulok el nagy titkot, ha a következtetés hasonló, mint amit itt ismételgetnek többen.
Egy Drupal.hu szintű szolgáltatás (subversion, levlisták, adatbázisok, webszerver) hardver/oprendszer/hoszting környezet beüzemeléséhez és folyamatos (úgy tűnik elvártan hibamentes) üzemeltetéséhez a hardver vásárlástól (ami tudjuk, hogy már eléggé olcsó) kezdve egy csomó szakértelem, több ember és idő kell. Nekem ezekhez nincs meg a teljes körű szakértelmem és az időm sem. A Drupal.hu kap egy ilyen szolgáltatást ajándékba, amit ÉN nem tudnék jobban megcsinálni (vö: idő/szakértelem hiány). Ezt én tudom értékelni. Nem tökéletes, de ettől nem rossz.
Konkrétabban az egy napos leállás az én személyes szempontomból nem nagy ügy, a kis mértékű adatvesztés szerintem kellemetlen, most szerencsére nagy gond nem volt. Mindenesetre szerintem nem fényezés, ha a közösség tudomására akarom hozni, hogy mi történt, és például miért vesztek el posztok. Szerintem jobb ötlet volt ezt leírni, mint látszólag megpróbálni elhallgatni/eltussolni a helyzetet. Mivel a helyreállítás érdeme nem az enyém (pedig volt vele munka, különben nem tartott volna ennyi ideig), gondoltam a nyílt forrású közösségek szemlélete szerint megköszönöm. De nekem úgy tűnik, mintha itt valami kemény üzletnek lenne nézve a Drupal.hu, mintha állandóan itt ülnénk mellette és simogatnánk, hogy nehogy valami fuvallat érje...
HG! Pont került a sessions tábla mizéria végére!
Megosztom a tanulságokat:
Beraktam az ominózus site-ra és egy jól működő kontroll site-ra debug kódot és az bizonyította, hogy tényleg nem fut le a session garbage az ominózuson, míg a másikon lefut időnként.
Tovább kerestem az angol drupal site fórumon és találtam haonló problémával küzködő kollégákat: http://drupal.org/node/58069 mely ezzel zárult: "PHP does this automatically based on your sessions_gc time. Not drupal's responsibility. read up on session garbage collection in php."
Tehát még egyszer nekilátam a php manual még tüzetesebb bogarászásának: http://www.phpfreaks.com/phpmanual/page/ref.session.html
Egybevetettem a phpinfo() által adott értékeket a manualban leírtakkal.
És hoppá! a session.gc_probability értéke a szerveren 0! Tehát a valószínűsége hogy a karbantartás elinduljon 0/100 :D
Ezután újabb ini_set sorokkal egészítettem ki a settings.php-t és gondolom nem csodálkoztok, ha most már elégedett vagyok a rekordok számával. a biztonság kedvéért a session.gc_divisor-t belevettem a default értékkel, hátha holnap ezzel viccel meg a szolgáltatóm :)
most így néz ki a kiegészítés:
ini_set('session.gc_probability',1);
ini_set('session.gc_divisor',100);
Tehát Hojtsy Gábor köszönöm, hogy segítettél a debug kóddal és helyes irányba tereltél ;) és fentartom, hogy nem kellett türelmesnek maradnom, paranoia rulez!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszi!
Köszönöm a sok beleölt munkádat / munkátokat! :)
Viszont lenne egy kérdésem. Felraktam, és rögtön figyelmeztet 3 db kritikus hibás patchelésre is. Ezek még korábban lettek megcsinálva (januárban) még rc3-4, stb -hez. Most nem teljesen értem, ez a véglegesbe nincs beépítve (azaz fel kell rakni a frissítést), vagy ez egyenlőre csak valami probléma amiatt, hogy frissen jött ki a végleges 6.0, és később már nem fog kérni patchelni, csak ha korábbi rc(Valami) van felrakva? (na jó, ezt az utolsó pár mondatot már én sem értem, remélem Ti igen :D)
A másik, ami nekem nem aktuális, de nektek hátha mond valamit. Mikor felraktam, akkor beállítotottam, hogy csak az admin regelhessen új felhasználót, plusz megadtam a "taltos" nevet admin névnek. Ezután próbáltam belépni a myvidoop.com -os openID-mel, ami szintén "taltos" nevű (korábban nem teljesen értettem hogy működik ez az openID), és ez fogadott:
http://taltos.unidev.hu/public/error.png
Mivel már beállítottam, hogy bárki regisztrálhat, etc, így nekem ez már nem fog bejönni valószínűleg, de ez nálam volt csak hiba, vagy másnál is ilyen warningolást fog dobni? (itt a másnál nem az én oldalam másik felhasználóját értem, hanem egy olyan másik embert, aki szintén drupal6-ot telepít, szintén beállítja, hogy nem regelhet más, és valaki mégis megpróbál openIDvel belépni)
Ennyi. Köszönöm mégegyszer! :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
idegen logika
Miért használod a Drupalt (vagy bármilyen tartalomkezelőt), ha nem akarod igénybe venni a szolgáltatásait? Egy teljesen idegen logikát akarsz ráerőltetni a rendszerre. A tartalomkezelők nem adatokat, hanem tartalmakat kezelnek. Annak nem sok értelme van a Drupalban, hogy a menü adatokat kiszeded az egyik adatbázistáblából, az ország adatokat a másikból, stb. Ezeket a megfelelő helyen webes felületen keresztül kell felvinni (pl. az országok lehetnek taxonómia kategóriák, a kaszinók egyedi tartalmak), és aztán ezeket a komplex tartalom-objektumokat kell a neked megfelelő módon megjeleníteni, listázni, átalakítani, stb.
1. Létrehozol egy kaszinó tartalomtípust (ehhez valószínűleg CCK kell neked, amivel a cím és a törzs mellett további mezőket tudsz definiálni).
2. Felviszed a kaszinókat, közben felcímkézed őket kategóriákkal (HU, UK, USA, HUF, GBP, USD, EUR, stb.), vagy ha bonyolultabb struktúrát szeretnél, akkor CCK node reference segítségével rendeled őket egymáshoz.
3. Listákat készítesz Views modullal. A Views űrlapon megadod a listához vezető útvonalat és a menüpont képernyőn megjelenő nevét.
Egy kicsit kattintgass körbe és legalább ismerd meg a rendszer alapkoncepcióját, szolgáltatásait, mielőtt nekiállsz PHP-val és MySQL-lel fát aprítani.