В общем, проблема с тонкостями, поэтому просто ткнуть носом в пункт админки не получится, хотя я бы и рад был такому простому решению.
Начну-ка я с самого, самого начала…
Однажды в одной из тем пользователь разместил 50 изображений. Зайдя в тему, я удивился тому, что страница очень медленно грузится. Скорость загрузки страницы очень хорошо видно в опере, которую я и использую обычно. Немного подумав, назрел вопрос о том, почему страница объемом 300 kb грузится 10 секунд со скоростью около 100 kb в секунду. Обычно у меня страницы разгоняются вплоть до 5mb в секунду, так как между мной и сервером гигабитка и 10 метров витой. Просмотрев на самом сервере загрузку процессора, в момент открытия страницы, я офигел. Процессор загружался на 100% в течении 10 секунд. Еще немного покликав на страничке, заранее исключив любое кэширование файлов браузером, понял, что именно формирование воблой миниатюр и пожирает все ресурсы.
Надо припомнить, что в одной из тем на данном форуме, тов. vGost пророчил мне такое развертывание событий…
В общем как я понял, миниатюрки не создаются во время приаттачивания и не хранятся до момента вызова, они потом формируются на лету, из-за чего и пожирается много ресурсов, о чем немного точнее уже писал vGost.
Не нужно иметь супермозг, чтобы понять, как будут обстоять дела при большом наплыве людей, которые хотябы впятером зайдут на эту страницу. В общем, я отказался от миниатюр, просто выключив их. В настройка приаттачивания изображений разрешил закачку картинок размером 800 на 1600 дабы не растягивать таблицу форума по горизонтали. Я понимаю, что это большой трафик, но форум в локалке, нам важнее ресурсы процессора.
Значит теперь размещаю я 50 изображений размером 800 на 1280, получается типа ленты изображений. Обращаюсь к странице и вижу, что скорость загрузки выросла до 1500 kb в секунду. Кто-то скажет а чего еще нужно, но я сей час всё поясню. Эти же 50 изображений лью по ftp на сервер и просто прописываю их тегом [img]. Вот тут то сорость загрузки страницы вырастает до 6 mb в секунду. Лезу на сервак и вижу, что при размещённых 50 изображениях аттачами, при открытии страницы загрузка сервера достигает 100% на 3-4 секунды, но гораздо меньше чем с миниатюрками. А вот при прописывании тегом [img] даже 100 изображений, загрузки практически нет. То есть секундный пик запроса в базу и все, потом остается только apache передать метров так 30 картинок.

Наверное сразу необходимо было сказать, что все аттачменты и аватары у меня находятся в ФАЙЛОВОЙ системе, а не в базе.

Итак, проблема еще не полностью описана, читаем далее…
Значит провел такой эксперимент. Вынес базу данных на отдельный сервер и поставил на ней MySQL Administrator, открыв закладку с графиками трафика и количества sql запросов. Немного понаблюдав, выяснил, что обычные страницы берут с базы очень мало, порядка 10-20 kb, а вот при открытии страницы с изображениями, когда там 50 приаттаченых картинок, график запроса прыгает то 1500-1800 kb и прокачивает так несколько секунд. После увиденного, у меня появились сомнения в том, что мои изображения в файловой системе. То есть потребление трафика из базы говорило об обратном, но чтобы развеять непонятки, я сделал кое-что. Чтобы убедится в том, что аттачменты в файловой системе, я просто напросто переименовал в web сервере папку attach_files на aattach_files. После этого, при обращении к странице с изображениями, я увидел вместо отображения картинок дыры, думаю никто не усомнится теперь в том, что аттачменты в файловой системе. Более того, в данной ситуации, когда apache не смог загрузить ни один аттачмент из-за неправильных путей к ним (из-за переименованной папки) на удоленном mysql-сервере всё-равно потребление трафика выросло до 1500-1800 kb, с соответствующей нагрузкой на цп 100% на несколько секунд.
А вот если например 100 изображений прописаны тегом [img], то запрос в базу очень маленький и не ресурсоемкий.

В итоге к чему все это я?
Да к тому, что есть железное правило о том, что задав нормально свой вопрос, всегда можно получить ответ. Надеюсь правила действует всегда.
Проблема очевидна. Расположение изображений методом аттачментов – это большая нагрузка на ЦП из-за ресурсоемкого запроса в базу. Почему, понять не могу, надеюсь народ поможет.
Я конечно понимаю, что для изображений необходима галерея, но дело не в этом. Все дело в том, что зашел к товарищу на портал ipb и там с этим траблов не обнаружил. Более того, стоит у меня блог, который так же приаттачисает файлы к публикациям в идее их ID, и выдает их при обращении к странице. Так я в нем вставлял одновоременно 440 изображений. Был секундный запрос в базу данных, а далее просто передача апачес трафика.
Ну что же, не примите за стихи. Давайте попробуем разобраться.

Хм... интересная штука...
Могу предложить самый хороший вариант - написать на vbulletin.org.
Текст с проблемой только самому нужно будет перевести или кого-то здесь попросить, а запостить поможем, если надо.

Azureus, я с этими вопросами занимаюсь уже более двух дет. Дело в том, что моё железо до сегодняшнего дня не могло обеспечивать должную производительность, и пришлось много времени посвятить выискиваю путей оптимизации.
Я могу помочь тебе, все прочел, но нужна дополнительная информация:
1. сведения о операционной системе uname -a и инфу о железе (память, проц, винты, точки монтирования)
2. версии php/apache/mysql (по возможности к mysql приведи опции компилирования)
3. среддее кол-во пользователей онлайн
4. настройки mysql (my.cnf)
5. информацию extended-status от mysql
если что-то не знаешь, загугли, или отпиши что знаешь
(на вборге не помогут)

Ну вот хоть кто-то отписался в теме, обычно такие тексты пропускают мимо глаз, сложно воспринимать.
Итак, начну по порядку. В общем, с кое-каких подсказок я посмотрел папке с аттачами файлы *.thumb и понял, что все-таки уменьшеные изображения лежат уже готовые, а не создаются при генерации страницы. Просто из-за тормозов с генерацией мне в подозрение попали именно они. Значит на удаленной машине с mysql, при умомянутом мною в этой теме сложном запросе в базу, загрузки центрального процессора практически нет, лишь пиковый скочок и все. Вся нагрузка проявляется на самом apache (у меня к нему подцепленна php5apache.dll). Ниже выведено 3 альтернативы диспетчера задач, с разной скоростью обновления. Вот там то и видно нагрузку.

Верхний - раз в 0.5 секунд
Средний - раз в 1 секунду
Нижний - раз в 5 секунд

Если посмотреть в скрин, то можно увидеть обычную активность, в виде разовых пиков к 100%. Это я и другие пользаки бродим по форуму. Ну и все наверное заметят на всех трех графиках, явно отличающийся долгой загрузкой огромный пик - это я открыл ту самую страницу с изображениями.

В добавок приаттачу скрин запроса в базу и потребление с нее трафика этой же страницей.

Вот на нем видно скачек запросов в плоть до 100 и потребления с базы трафика в 1.2mb несколько секунд.

1. сведения о операционной системе uname -a и инфу о железе (память, проц, винты, точки монтирования)

WinXP apache 1.3.33 + Mysql 4.1.9 + vBulletin 3.5.2 Athlon 2800+; 1024ddr; HDD120 SB NTFS

3. среддее кол-во пользователей онлайн

Только не смеятся от 1 до 5 В день около 100
В этом то и дело, что нагрузка не от юзеров а именно от конкретного случая с изображениями. Ресурсы постоянно свободны.

4. настройки mysql (my.cnf)
5. информацию extended-status от mysql

Всё по дефолтам.

Хм... интересная штука...
Могу предложить самый хороший вариант - написать на vbulletin.org.
Текст с проблемой только самому нужно будет перевести или кого-то здесь попросить, а запостить поможем, если надо.

Нужно чтобы кто-то у себя попробовал. Естественно в интернете не заметно, но когда обычнов локалке страница грузится 0.5 секунды, а тут не с того ни с сего 10 секунд, то появляются мысли...
Да и всем побоку, что там у хостера, а я сам себе хостер, может и трабла в этом.

Твоя проблема в платформе и конфигурации железа и ПО, одним словом, в том, что ты сам хостер. Для информации прочитай эту тему.

Далее конкретные советы.

1. Если можешь, поставь отдельную тачку с Linyx.
Если не сможешь, то
- обнови версию mysql и php (очень важно)
- верни аттачи в базу
- через вложения->поиск удали все аттачи, превышающие размер 250k
- через обновление счетчиков сделай перестроение миниатюр вложений (размер установи 80-100 пикселей предварительно)
- верни опцию отображать миниатюры вложений
- сделай свой файл конфигурации my.cfn примерно следующего содержания (за основу возьми из дистра для виндов)

[client]
password	= password 
port		= 3306

[mysqld]
port		= 3306
socket		= /tmp/mysql.sock
set-variable	= key_buffer=16M
set-variable	= myisam_sort_buffer_size=64M
set-variable	= join_buffer_size=1M
set-variable	= read_buffer_size=1M
set-variable	= sort_buffer_size=2M
set-variable	= table_cache=1024
set-variable	= thread_cache_size=64
set-variable	= wait_timeout=1800
set-variable	= connect_timeout=10
set-variable	= max_allowed_packet=16M
set-variable	= max_connect_errors=10
set-variable	= query_cache_limit=1M
set-variable	= query_cache_size=16M
set-variable	= query_cache_type=1
set-variable	= thread_concurrency=16
skip-locking
skip-innodb
log-bin
server-id	= 1


[mysqldump]
quick
set-variable	= max_allowed_packet=16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
set-variable	= key_buffer=64M
set-variable	= sort_buffer=64M
set-variable	= read_buffer=1M
set-variable	= write_buffer=2M

[myisamchk]
set-variable	= key_buffer=64M
set-variable	= sort_buffer=64M
set-variable	= read_buffer=1M
set-variable	= write_buffer=2M

[mysqlhotcopy]
interactive-timeout

Из опционального - поставь второй винт и перенеси базу на него.
Повторяю, на вборге засмеют, расчитывать на виндах неначто.

Originally Posted by intolerance

Твоя проблема в платформе и конфигурации железа и ПО, одним словом, в том, что ты сам хостер. Для информации прочитай эту тему.

Вопрос о том, что скоро всё переедит на freebsd уже решен мной, но не реализован. Пока только скачал дистрибутив и доки. Думаю, что в течении месяца сам ко всему прийду, просить никого не хочу.

Originally Posted by intolerance

1. Если можешь, поставь отдельную тачку с Linyx.

Могу, ставил как-то себе мандрейк, познать... но теперь вроде как решил фриху, о чём писал выше.

Originally Posted by intolerance

- обнови версию mysql и php (очень важно)

php стоит 5.1.0 Мускул обновлю конечно до последней ветви 4.**, а вот что-то с 5 и воблой были траблы у меня лично при установке.

С конфигом мускула попробую не седня так завтра .

Originally Posted by intolerance

- верни аттачи в базу
- через вложения->поиск удали все аттачи, превышающие размер 250k

Дружище. Я конечно попробую, но мне кажется что размер имеджей не причем. Вот тут ковырял дома и сделал такой тест.
Взял и тупо переименовал папку аттачей и обратился всё к той же злосчастной странице. Смотри скрин ниже, потом пояснение:


Значит как видно скорость загрузки страницы очень мала, это потому, что сам трафик, который показывает опера отсутствует из-за отсутствия изображений. Если присмотреться, то можно увидеть, что страница грузится уже 16ую секунду. Но правда это уже 140ое из 152ух изображений. В этот момент, в диспетчере задач та же ситуация, которуую я выкладывал выше на скрине. То есть страница не грузится быстрее, так как проц прилип к потолку. Опять же, картинок нет вообще, только ссылки на них, доставаемые из базы. Поставил себе vBDebug Mode, зашел на эту страницу и увидкл, что она сгенерирована за 0.2222 секунды, короче типа проблем нет. Но ведь явно видно, что трабл не из-за больших имеджей (их то после переименования папки с аттачами нет вообще), а из за запроса в базу данных за "кординатами" картинок.

Эх, видимо не осилить зверя эдаково :( ...

Azureus, пойми, количество переменных, которые здесь могут играть роль значительно больше, чем ты можешь представить. Направление, в котором ты копаешь совершенно не то. Бесполезно смотреть на скорость загрузки браузером. Большая часть настроект станет приемлемой только после того, как ты перейдешь на юникс и установишь корректно (читай через порты если фря) твои приложения. Далее пройдешься по всем конфигурационным файлам, и сделаешь корректировку значений по умолчанию. php на юниксе не отожрет 100% от камня, и даже сейчас ты можешь включить логирование медленных запросов.

Я уже неоднократно писал, что не советую ставить mysql 5-ой ветки, ставь 4.0.x/4.1.x. Выбор FreeBSD для неопытного пользователя может сыграть злую шутку. Если решишь ставить FreeBSD, то учти 2 очень важных момента:
1. Поставь 2 диска, и сделай точки монтирования /usr и /var на разных дисках
2. Компилируй mysql с линукстредами, как я писал во врезке приведенного выше линка (админам: сделайте линки - линками, с подчеркиванием хотя бы)

Твоя ситуация сейчас - это гаданье на несвежем софте на нестабильной тачке - тупиковый путь. Либо логируй медленные запросы к базе

When started with the --log-slow-queries[=file_name] option, mysqld writes a log file containing all SQL commands that took more than long_query_time seconds to execute. The time to get the initial table locks are not counted as execution time.

и прочеши свой php.ini, посмотри логи апача. Ты же совсем не тем занимаешься!

intolerance,
Спасибо за советы. В течении нескольких дней что-нибудь попробую.

Originally Posted by intolerance

Направление, в котором ты копаешь совершенно не то. Бесполезно смотреть на скорость загрузки браузером.

Да дело то не в браузере. По нему я просто увидел, что страница давольно таки тяжела в отличии от других. Для меня проблема в 100% нагрузке на проц 10 сек, хотя я уже повторяюсь.

Originally Posted by intolerance

Я уже неоднократно писал, что не советую ставить mysql 5-ой ветки, ставь 4.0.x/4.1.x.

Метю в 4.1.16

Originally Posted by intolerance

Выбор FreeBSD для неопытного пользователя может сыграть злую шутку.

Как оказалось, у винды шутки площе (образовано от плоские). Да и говорят, что найти источник проблем в nix проще.
В общем через жопу нет привычки делать, постараюсь. Сайты поддержки и доки есть. Есть и машина для тестирования, так что по чуть-чуть осилим. Вот только у меня и есть два винта, но я хотел их застрайпить в один.

Originally Posted by intolerance

1. Поставь 2 диска, и сделай точки монтирования /usr и /var на разных дисках
2. Компилируй mysql с линукстредами, как я писал во врезке приведенного выше линка (админам: сделайте линки - линками, с подчеркиванием хотя бы)

Ушло в заметки.

Originally Posted by intolerance

Твоя ситуация сейчас - это гаданье на несвежем софте на нестабильной тачке - тупиковый путь.

Что несвежего то, непонимаю. Вторая ветвь апача у меня стаяла, постоянно выпадала ошибка на одну dll. На руборде подсказали, что со втрой ветвью + php5 у всех так. Ну базу есно обновлю. PHP свежак.

Originally Posted by intolerance

Либо логируй медленные запросы к базе

Прости, немного не понял, куда код то загнать?

Originally Posted by intolerance

и прочеши свой php.ini, посмотри логи апача. Ты же совсем не тем занимаешься!

Логи апача переодически посматриваю. Вот php.ini то же видел, но особо там ничего не менял. Могу его просто приаттачить, взглянешь.

Azureus добавил 07.02.2006 в 06:08
Сегодня опять мучал двиг тестами. Опять же немного поправляю сам себя. Пофигу какие изображения, большие или маленькие, нагрузка одинакова. Просто когда я смотрел на загрузку миниатюрок, их в масштабе моего экрана бвло штук 30, а когда полных изображений. то одно. К тому же полные изображения создавали эффект быстрой загрузки тем, что скорость у оперы была до 2 метров, а это просто был эффект загрузки большего трафика.
И еще, опять же напомню. Грузит не база данных, грузит apache c подгруженой dll. Когда выносил базу данных на другой компьютер, то на сервере с mysql все мои эксперементы виделись мелким пиком к 100%, а на машине с апачем, как на скринах выше, ну может немного ниже. Думаю подгрузить ка ему php.exe и посмотреть, уйдет ли нагрузка с апача на php.exe.
Как сделать так, что бы мускул стал использовать my.cfn

Р.S
Сегодня добрался и обновил мускул до 4.1.16, ситуация прежняя :(

Azureus, стоп-стоп, если уж продолжаешь дергать на виндах, то снеси всю комбтнацию софта, предварительно сделав бэкап базы и wwwroot и поставь проверенный дистр из серии Installation Kits, например Apache Friends XAMPP или Appserv. И вот тогда скажи результаты.

http://hotscripts.com/Detailed/26145.html
http://hotscripts.com/Detailed/24570.html

про логирование медленных запросов, зы код втыкать нужно в my.cfn, читай доки.