Кастомные галеры, чем?

LemonS писал:

1. Это +500к каталогов , index.html и прочего, что кешируется ОС, иначе ему надо в таблице размещения файлов каждый раз искать где это и что это. Тратиться память, нагружаем лишний раз диск.

А ты посмотри как сделана структура в том же squid и прочих кеширующем софте. Там наверное не просто так сделали вложенность директорий в 5 уровней.
У системы как раз более глобальный пиздец наступит, если все файлы стараться в одну директорию запихать.

Stek: ну судя по тому что люди думают что ссылки вида xvideo/video12345/asd/ это статиска то видимо они так же думают что у xvideo на корне миллионы каталогов

LemonS писал:

st01en: те вы считаете что скрипт держит в базе сами тумбы и скрипт же как-то кеширует сами тумбы ? Или вы считаете что поиск по базе одной записи со списком тумб галеры это операция которая занимает хотя бы 0.1% ресурсов сервака ?

Где я писал про сами тумбы? Держит записи конечно.
Я считаю, что для сиджетуба смысла делать каталоги нет. Так же как и для тубов, где видео обычно разбросано на нескольких серверах. Тут хочешь-не хочешь, а придется динамически генерировать урлы.
А вот для сиджа, особенно пиксового, с контентом, который весь хранится на собственном сервере - есть смысл в отдельных каталогах.
Конечно, поиск одной записи потребляет мало ресурсов, но если в секунду 1000 запросов? или 100000? Многопоточность? В пхп? На хабре до сих пор об этом спорят
К тому же, вся операция с динамическим контентом - это не только пхп.
Начнем с реврайтов, их обрабатывает апач. Апач не самый шустрый веб сервер, будут тормоза при одновременной обработке 1000 реврайтов?
Далее вывод тумбы. Разве все записи одной гали хранятся в одной таблице? Сомневаюсь. Значит джойны, или юнионы, или селекты в селектах, или селекты за селектами. Что при базе в 500к галь будет полюбому жрать ресурсов немеряно.
Ну и наконец, зачем создавать многоуровневые вложения? Достаточно 2-3 уровней.
/datetime/galid/title/ например.
один запрос к одной таблице с галями, который выбирает id, datetime и title, и склеивает в путь

Код: [развернуть]

opendir(DIR, ”$path”); @files = grep(/jpg$/, readdir(DIR)); closedir(DIR);

и потом уже в темплейте делать реврайт uri на url.
ну правда, это не пхп.
и вот в таком варианте, думаю, чтение файлов и каталогов будет практичнее реврайтов и чтения базы.

st01en: без улыбки это читать невозможно )
Ок, дайте знать как напишете и сравним что быстрее )

Цитата:

В пхп? На хабре до сих пор об этом спорят

На хабре давно две любимые темы - обосрать копирайт и пхп. При том, в 99% обсирающие ни в пхп ни в копирайте ничего не понимают

Цитата:

Начнем с реврайтов, их обрабатывает апач. Апач не самый шустрый веб сервер, будут тормоза при одновременной обработке 1000 реврайтов?

Вроде все вменяемые давно на nginx перешли. А рерайты на самом деле апач обрабатывает моментально. Только надо их писать в конфиг домена, а сам .htaccess отключать, что бы не искало его при каждом запросе.

Ну и потом, никто не мешает галерею сгенерировать и закешировать ее, отдавая уже как чистую статику. А там по нужным условиям удаляем кеш, и получаем перегенерацию заново. Т.е. дальнейших возможностей оптимизации достаточно.

Stek: Можно пример того, как в конфиге домена вписать реврайты?

Да то же самое. В секции, которая описывает виртуальный домен, вписываешь так же реврайт правила.

LemonS писал:

st01en: без улыбки это читать невозможно ) Ок, дайте знать как напишете и сравним что быстрее )

Смех - это хорошо
Зачем что-то писать и сравнивать? И так видно, у кого длиннее.....цикл вывода галереи
Ваш(раз уж мы на вы =)) вариант:
1.Запрос к серверу.
2.Реврайт
3.Запрос к базе.
4.Компиляция темплейта.
5.Вывод страницы.

Мой вариант:
1.Запрос к серверу.
2.Запрос к базе
3.Компиляция темплейта.
4.Вывод страницы.

Как видим, у вас длинее на один шаг.
Но суть то не в этом. Я же просил пояснить, почему так плохо иметь физические каталоги, расположенные не в папке скрипта, а скажем, в папке galleries, в корне домена. Ну кроме того, что это не кошерно

Нашел сиджетуб на смарте и посмотрел структуру.
/scj/thumbs/6/380gal_title.jpg
/scj/thumbs/5/806gal_title.jpg
/scj/thumbs/4/986gal_title.jpg

И простите, но чем это отличается от такого, кроме названия папок?
/galleries/111/1.jpg
/galleries/112/1.jpg
/galleries/113/1.jpg

Лично я в этом не вижу никаких минусов. Я еще раз повторю, что я не говорю о статических хтмл, а только о удобной структуре каталогов.

Stek:
На чистый нгинкс? Слышал о таких ниндзя, но вживую не видел И от htaccess- отказаться тоже не получается - вордпресс пишет реврайты, инкси пишет, смарт пишет, кристалл баненные домены туда пишет.

st01en: без реврайта надо статический index.html по указанному урлу. Я не понял как в этом случае решается вопрос темпелйта и его кеширования.

Вы считаете что в nginx нет реврайтов?

st01en писал:

На чистый нгинкс? Слышал о таких ниндзя, но вживую не видел smail101.gif И от htaccess- отказаться тоже не получается - вордпресс пишет реврайты, инкси пишет, смарт пишет, кристалл баненные домены туда пишет.

Вордпресс, смарт - давно уже имеют у себя в доках описание, как нужное правило на nginx изобразить.

st01en писал:

Нашел сиджетуб на смарте и посмотрел структуру. /scj/thumbs/6/380gal_title.jpg /scj/thumbs/5/806gal_title.jpg /scj/thumbs/4/986gal_title.jpg И простите, но чем это отличается от такого, кроме названия папок? /galleries/111/1.jpg /galleries/112/1.jpg /galleries/113/1.jpg

Можно реврайтом превратить /scj/thumbs/ в /galleries/, можно симлинком, а можно в самом скрипте указать диру для сохранения тумб и будет как ты отписал. + Раньше смарт так и обзывал картинки 1.jpg, 2.jpg ... Сейчас более продвинуто, в зависимости от описания галеры. (ХЗ, кстати, как это отключить!).
По сути, ты ничем не ограничен в этом плане.

Господа, отклонились от темы, подскажите плиз, какой из ротаторов под пиксы заюзать, что бы можно было нагенерить кастом галерок ? ( смарт не предлагать )

DTR... для несложных галереек вполне подойдет...

Doctor: Спасибо!