По роду деятельности часто приходится устанавливать firebird и не на стандартный порт + несколько инстансов на одном сервере, решил упростить задачу и с коллегой сделали установщик с помощью InnoSetup. Установщик позволяет быстро установить SuperServer Firebird 2.5.2 26540 на нужный порт и с нужным наименованием службы, для нескольких серверов в одной системе. Также он проверит существование уже существующих служб с выбранным именем и при обнаружении конфликта не даст продолжить. Удаляется установка вместе со службой и файлами.

Кому интересно - могу выслать исходники от InnoSetup

Брать тут: http:/www.palarity.com/fb_2_5_2_setup.exe

Держите.
http://www.palarity.com/FirebirdSetupSrc.rar

Добавить поле ввода пароля для sysdba - орошая идея, думаю что сегодня добавлю.
А что касается пользователей, так это действительно избыточно. Если их стандартный набор, то можно просто security2 подсунуть подготовленный или через ibexpert делать, в любом случае это нужно будет делать или в установщике или в эксперте. Так зачем велосипед изобретать, если он уже есть...

Главная идея была в том, что приходится возиться с командной строкой, создавать попапочки, копировать файлы и прочее, в том случае если нужно сделать второй инстанс... С этой задачей установщик справляется очень просто.

Симонов Денис,
Потому что под винду рекомендуют ставить супер сервер, и он ставится по умолчанию :)

http://www.firebirdsql.org/manual/ru/qsg15-classic-or-super-ru.html

kdvrpalaznikПотому что под винду рекомендуют ставить супер сервер
ШТО? :-)
суперсервер рекомендуют только когда
- мало пользователей
- пользователи выполняют легкие и короткие запросы

потому что пока супер не распараллеливается, и любой тяжелый запрос заткнет всех остальных пользователей.

Ну как это ШТО, написано же:
Classic Server : авторНа каждое пользовательское соединение создается отдельный процесс со своим кэшем. При малом количестве соединений потребляется меньше ресурсов. Т.е. при большом - много жрет, по этому ваше первое утверждение неверно. Про второе замечание не думал ни когда, но похоже оно имеет место быть. Руководствовался только рекомендацией с авторитетного ресурса где написано:
авторЕсли Вы все еще не уверены, что именно выбрать (возможно, технические подробности показались Вам чересчур сложными для «Быстрого старта») воспользуйтесь следующим правилом:

Под Windows выбирайте Superserver.
Под Linux, просто выбирайте один или другой вариант. В большинстве случаях, скорее всего, Вы не заметите разницы.

Всем спасибо за разъяснения, обоснованная критика всегда полезна. Обновили установщик, теперь можно ввести пароль sysdba и выбрать какой сервер устанавливать SS или С. (iss - http://www.palarity.com/FirebirdSetup25.rar exe - http://www.palarity.com/Firebird25.exe)

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

SupperServer 0 подвисших - 1s 903ms, 1 подвисший - 3s 370ms, 2 - 4s 976ms, 5 - 8s 829ms 15 - 25s 756ms
ClassicServer 0 подвисших - 1s 940ms, 1 подвисший - 3s 42ms, 2 - 4s 212ms, 5 - 6s 68ms 15 - 12s 246ms

Из чего можно сделать вывод что реально Classic лучше. Еще хотелось выяснить насколько страдают все пользователи при выполнении одним одним пользователем тяжелого запроса и понять можно ли распараллелить работу SupperServer. Оказалось что татального зависона не происходит и условно можно работать дальше... Заметил что при подключении 2х клиентов с бооольшими запросами на SS происходит выделение процессу 25% всего процессорного времени, когда 2, самых загруженных ядра (из 4х) системы загружены только до половины, это может говорить, что сервер обслуживался сразу 2я ядрами системы одновременно.

При эксперименте еще заметил, что при большом числе > 10 подвисших процессов на Classic система тратит больше оперативной памяти, чем SS.

Ivan_Pisarevsky rpalaznikтехнические подробности показались Вам чересчур сложнымиЧто правда подробности так сложны? Я так полагаю Дима написал это, как в анекдоте про "а когда рецепт совсем не читается, то мы даем вот ЭТУ микстуру". А в самой статье рецепт как раз прописан вполне разборчиво.

На самом деле я не увидел, что речь идет о 1.5... И прочитав рекомендации понял что в одном случае 1 процесс и много потоков, в другом случае много процессов с одним потоком в каждом. К сожалению опыта и знаний не хватило чтобы точно понять какой вариант выбрать, по этому решил сделать по совету... Теперь, благодаря, в том числе и вам, разобрался в этом вопросе, спасибо!

И если подвести итог - т.к. проблем с распараллеливанием с версии 2.5 нет, то кол-во ядер роли не играет в выборе типа, Classic идеально подходит в базах, где могут часто встречаться тяжелые запросы, в случае небольшого кол-ва подключений и на аппаратной платформе нет проблем с оперативной памятью. SS используем там где нет большого кол-ва тяжелых процессов, при большом кол-ве подключений, и есть проблемы с памятью

В приоритете конечно тяжелые запросы, все остальное на втором плане и по умолчанию стоит использовать именно Classic, а не SS.