1. Большой буфер для хранения. 500-1000 клиентов на сервер... многовато. Ещё ведь и сериализатор этого добра там нагрузки подкидывает.
2. Безопасность. Я не смотрел - там сессия хэшируется по виртуальному хосту?
3. Техническая невозможность у хорошего такого процента хостеров - достаточно много кто использует различные патчи к апачу, сводящиеся к различным модификациям форка оного на каждый запрос.

Разница есть большая. Чтобы не гадать с кофейной гущи, как все привыкли на форумах, надо иметь исходные данные. Естественно если актуально получить дельный совет, а не всевозможные варианты советов.
Теперь дали больше информации и уже более менее можно судить о нагрузке. Можно ещё уточнить. Вот к примеру форум на том же SMF и статистика штатная и Awstats. Сравните данные и укажите отличия. Тогда можно уже будет оценивать.


Это не разумно, так как в основном пользователи приходят от поисковиков. И чем больше у поисковика в кармане лежит, тем лучше.

Если готовитесь к войне с хостёром, тогда есть смысл что то писать и искать червей. Но я лично не вижу смысла воевать. Надо просто договариватся цену, за которую хостёр готов представлять услугу. И дальше уже решать. Проблема та, что хостёры в основном штатные цены указывают для сайтов, которые вобще не посещаемые, таких сайтов наверно 90%. И когда поселяется сайт уже с каким то посещением, начинается война....

1. Количество pconnect-ов = количеству сайтов (пусть 500-1000), но в случае connect количество соединений с БД = количеству обрабатываемых посетителей (предположим на одного посетителя приходится один скрипт работающий с БД), таким образом количество соединений в втором случае прямо пропорционально количеству посетителей и скорее всего превышает количество сайтов. Создание нового соединения это длительный процесс, который может быть на 1-2 порядка дольше чем выполнение простого SQL-запроса, значит скрипты в которых создаются новые соединения работают дольше и создают повышенную нагрузку на сервер и БД

2. Вроде нет, но точно не знаю. По моему хэшируется по хост/логин/пароль, но не вижу в этом угрозы для безопасности

3. Понятно что разговор о вреде/пользе постоянных соединений возможен если они поддерживаются у хостера.

MVK, искренне когда-то думали, что постоянные соединения добро на вирт. хостинге. Но потом решили проверить. Уж не знаем почему, но нагрузка и тормоза при пконнектах были выше. Несколько раз переключение с пконнектов в обычные - успокаивало хостера бушующего по поводу нагрузки. Объяснять это затруднимся, оставим это теоретикам

В нашем случае это вполне оправдано.
1. в галерее не так много есть, что индексировать - картинки одни...
2. это сайт 700 квартирного дома. мне в принципе не очень большое дело до поисковых систем - вся целевая аудитория находит сайт по объявлениям на семи парадных... хотя моему тщеславию приятно, что сайт находится через поисковые системы...

- кстати в PHP5 по умолчанию connect использует pconnect

Угу. Есть только одно "но" - точно так же количество соединений равно количеству одновременных скриптов. У MySQL сессия - это коннект. Вам придётся сериализовать либо запросы в рамках одного коннекта (ну это вряд ли по многим причинам), либо коннекты. Не уверен что система не теряет на одних только разборках с блокировками. При этом в памяти висит это всё ещё. Подозреваю что у каждой дочки апача свой экземпляр преконнектов.



Согласен.



Вопрос только в том что это достаточно много хостеров

И?

Топикстартеру мой добрый совет - выкиньте gallery2. Это "приложение" жутко тормозное и памятежрущее. Единственная приятная фишка в нем - загрузка файлов по webdav. Больше в ней ничего вкусного нет. Ищите более легкий аналог. Абсолютно серьезно говорю, как человек перелопативший и друпал и SMF и пытавшийся использовать gallery2. Заодно и php модулем будет, что прирост производительности даст весьма ощутимый.

- ну, это я к тому что Вы действительно уверены что Вы не использовали pconnect (не явно)? короче что Вы писали в xxx_connect(...) кроме данных необходимых для создания соединения

1) Вообще мы тестировали на php4, может в php5 что-то и изменилось конечно, проглядели что у ТС php5, наша вина.
2) Дайте линк на информацию, где сказано что mysql_connect в php5 делает постоянные соединения по умолчанию. Только, пожалуйста, не на коммент от 2006 года в мане, а на официальный ман или скажите что Вы лично это проверяли.

- параметр new_link, цитата из мана:

Вы не вполне корректно поняли эту цитату. Это относится к вызову mysql_connect внутри одного скрипта. Т.е. если Вы в одном скрипте вызывали 10 раз подряд mysql_connect, то он вместо новых соединений, будет возвращать старый идентификатор. Ну по типу синглтонов.
Но после окончания работы скрипта соединение будет закрыто и новый скрипт будет использовать новое соединение, в отличии от ситуации с использованием mysql_pconnect.

Я с вами не соглашусь по некоторым позициям...
в Gallery2 есть много вкусностей - интеграция с SMF (как по базе пользователей, так и в интерфейс), права доступа (мы их используем), модульность и апдейты этих модулей, хорошая поддержка (в смысле инфы много) и многое, многое другое...
Перед тем как выбрать Gallery2 я посмотрел несколько разных ПО для Галереи и по совокупности критериев Gallery2 однозначно выиграла. К сожалению на производительность я тогда не очень обращал внимания.

Что же до замечания на счёт работы как модуль - увы, это зависит не от самого ПО галереи, а от библиотеки GD (или аналога), который используется для изготовления превьюшек (и ещё некоторых операций с картинками). Когда софт работает как модуль возникает две проблемы -
1. нельзя запускать внешние программы (хостер отключает в php всякие system), а софт галереи может использовать такие программы.
2. когда же используется php библиотека для работы с картинками она упирается в MemoryLimit и не процессит картинки. (когда php используется как cgi я могу менять MemoryLimit) Сейчас у хостера MemoryLimit в php как модуле установлен в 16Мб, на большее хостер не пойдёт (я и этого-то еле добился), и этих 16Мб не хватает на большинство фоток, которые делаются современными цифровиками. Можно, конечно, предобрабатывать фотки на локальном компе, но мне так не хочется усложнять пользователям сайта жизнь, что я пока не готов рассматривать этот вариант.

В любом случае, я признателен вам за совет избавиться от Gallery2 и с признательностью бы выслушал совет Гуру по альтернативе.

Что ещё интересно, мой хостер сам предлагает установить Gallery2 - т.е. у него есть раздел установка приложений и там Drupal, phpBB, WordPress и Gallery2.

Да, согласен, именно для этого ставим 128 или самый крайний 64 МБ.

Ну тут уж конечно нужно соизмерить потребности с возможностями. Если уж без gallery2 совсем никак, то тогда на высший тариф или VPS (второе скорее всего вероятнее). Просто сообщил, что данное ПО потребляет ресурсов неадекватно предоставляемому сервису. Или искать аналог. Решать, как всегда, только вам.

На VPS пока не готовы по деньгам.
А про аналог - нет ли у вас совета этого самого аналога?

Мне вот так вот сложно вам советовать, ибо я разработчик, так что ели меня чего не устраивает - лезу и правлю руками, аналоги ищу лишь поверхностно.
К примеру по потребности интеграции с SMF сразу выплыла Coppermine http://www.simplemachines.ru/index.php?topic=1267.0
А при друпальной галерее есть неплохое решение с Views - получается фликероподобные галереи с тэгами- http://www.lullabot.com/articles/how_to_bu...lickr_in_drupal

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

Не знаю, решится ли с ограничением на 16мб памяти, но по логике, если приложение потребляет мало, то и памяти должно больше GD доставаться.

Не надо верить расказам. Не сам скрипт жрёт память, а именно конвертация. И если надо конвертировать фотки размером в 4 МБ, придётся выделять не менее 128 МБ для процесса. 16 МБ памяти на сегодняшний день издевательство....

adnull, спасибо!
Coppermine однозначно смотрел, но что там не понравилось не помню... вроде там с юзабилити были косяки и с раздачей прав... (с меморилимит там были теже самые проблемы)
Друпаловское решение может быть посмотрю...
Я тож разработчик... но писать своё сейчас времени не хватит (да и не веб я разработчик), а подправлять чужое дело неблагодарное - особливо если речь идёт об оптимизации...


gylys:
>>16 МБ памяти на сегодняшний день издевательство
ХА! когда сайт первично разворачивали мы сидели у хостера А. там было ограничение МемориЛимит=8Мб.
Потом решили переходить на хостера Б (о том о ком речь сейчас). У Б было хорошее соотношение услуг и цены и вдобавок его рекомендовал сисадмин с работы, который у Б уже держал несколько проектов.
Я договорился со своим админом попробовать мои приложения в пределах его, админа, аккаунта. Попробовали - всё пучком и даже МемориЛимит=16Мб.
Отлично! Проплатили хостеру денег за год, начинаю разворачивать приклады - опппаньки - меморилимит=8Мб. Тариф тот же самый, что и у моего админа, в спецификации тарифа указано 16Мб.

Мне потребовалось два дня на доказательство техподдержке, что прав я, а не они. У них было два аргумента - переходите на VIP тариф и запускайте приложения как cgi (а я тогда не понимал, что это означает).
Через два дня они плюнули и поменяли на 16. К этому времени я уже знал что такое запуск через cgi и перевёл приложения на такой запуск.

А вы про 128 говорите....

coppermine вроде с imagemagick умел работать, если хостинг это не запрещает, то это плюс определённый.