Érdekelne, hogy vajon a kód ezen része által okozott sebesség csökkenés miatti anyagi plusz költség hogyan aránylik a plusz munkaórák költségével ami az ilyen kód javításához szükséges. ;) Tehát nem mondanám azt, hogy felesleges vagy rossz beidegződés lenne ez, bár vannak olyan vélemények, hogy bizonyos esetekben nem gyorsabb a szimpla idézőjel. http://www.sematopia.com/2007/08/php-double-quotes-vs-single-quotes/#com... Szóval én ilyen esetben nem látom értelmét.

Arról meg most ne beszéljünk, hogy a db_query() úgy is rátol egy preg_replace_callback()-t ami nem a sebességéről híres. Ráadásul azon a lekérdezésen is van mit csiszolni (http://forge.mysql.com/wiki/Top10SQLPerformanceTips).

pp

megosztott tárhelyen egy elég durva taxonomy nézettel (kb. 120 node bevezetője, címe, CCK link mezővel) és hasonlóan erőforrás zabáló node nézettel 2000 egyedi látogató / napot is megéltem, gond nélkül. A lényeg, hogy a css, js és adatbázis gyorstárazás legyen bekapcsolva, de ezt szerintem anélkül is simán menne.

De sok ezer látogató felett sem kell pánikba esni

A CSS Gzip és a Javascript Aggregator pl a css és js fájlokat becsomagolja gzip-be, így kevesebb adatot kell a szervernek átküldenie. Itt vannak konkrét számadatok is

Legvégső esetben meg ott van a Boost, ami statikus, becsomagolt fájlt gyárt az oldalakból, állítólag nagyon hatékony, sajnos még nem kellett. :)

1. OpenID van a Drupal 6.x-ben alapból.
2. CAS http://www.longsight.com/blog/drupal-cas-single-sign-on
3. hopp ez most nincs meg, de van egy jó kis modul erre

Még egy kis olvasni való:
http://drupal.org/node/43816

Én valószínűleg a kettes irányába indulnék, de lehet ez neked nem lesz jó. Annak idején én próbáltam a táblaosztásos dolgot, de annyi probléma volt vele, hogy mostanában már csak hanyagolni tudom. Mire az ember összekalapál egy többé kevésbé működő rendszert jön egy frissítés és kezdheti kb előröl. Nem beszélve a modulokról és arról, hogy ha skálázni kell akkor is meg vagy lőve egy ilyen megoldásnál.

pp