From: Thomas S. <ts...@ib...> - 2012-03-21 13:22:25
|
Hello, it seems I can't install SC of Firebird 3.0 as a service. There is no appropriate .bat file for that. While I could create one or take the one from 2.5, instsvc.exe in the 3.0 snapshot is out-dated, at least according to the usage information, as it doesn't support the -m[ultithreaded] switch. So I guess this area needs some consideration? Thanks, Thomas |
From: Alex P. <pes...@ma...> - 2012-03-22 08:06:58
|
On 03/21/12 17:22, Thomas Steinmaurer wrote: > Hello, > > it seems I can't install SC of Firebird 3.0 as a service. > > There is no appropriate .bat file for that. While I could create one or > take the one from 2.5, instsvc.exe in the 3.0 snapshot is out-dated, at > least according to the usage information, as it doesn't support the > -m[ultithreaded] switch. > > So I guess this area needs some consideration? >From command line switches POV there is no difference in FB3 between SS and SC - they both are 'single process serving multiple connections'. But if instsvc does not support -m, you can't install SS too. |
From: Dmitry Y. <fir...@ya...> - 2012-03-22 08:21:29
|
22.03.2012 12:06, Alex Peshkoff wrote: > From command line switches POV there is no difference in FB3 between SS > and SC - they both are 'single process serving multiple connections'. > But if instsvc does not support -m, you can't install SS too. You can, as it still has options "superserver" and "classic". The former one implicitly adds the -m switch behind the scenes. In order to set it up as SuperClassic, you need to install it as "super" and change firebird.conf appropriately. Dmitry |
From: Thomas S. <ts...@ib...> - 2012-03-22 08:29:40
|
Hi Alex, >> it seems I can't install SC of Firebird 3.0 as a service. >> >> There is no appropriate .bat file for that. While I could create one or >> take the one from 2.5, instsvc.exe in the 3.0 snapshot is out-dated, at >> least according to the usage information, as it doesn't support the >> -m[ultithreaded] switch. >> >> So I guess this area needs some consideration? > >> From command line switches POV there is no difference in FB3 between SS > and SC - they both are 'single process serving multiple connections'. > But if instsvc does not support -m, you can't install SS too. I think I see now how it works. ;-) Using: install_super.bat FB_300_x64 I get the following executable path for the Windows service: "C:\Program Files\Firebird\Firebird_300_4051\firebird.exe" -s FB_300_x64 -m Using: install_classic.bat FB_300_x64 I get the following executable path for the Windows service: "C:\Program Files\Firebird\Firebird_300_4051\firebird.exe" -s FB_300_x64 => Does that mean: We have a single executable in Firebird 3. When -m is used, this means a single server process and the SharedCache, SharedDatabase parameters controll whether it's SS or SC. When -m is not used, then it's one process per connection thus CS. Is this correct? Thanks, Thomas |
From: Dmitry Y. <fir...@ya...> - 2012-03-22 08:38:33
|
22.03.2012 12:29, Thomas Steinmaurer wrote: > > => Does that mean: We have a single executable in Firebird 3. When -m is > used, this means a single server process and the SharedCache, > SharedDatabase parameters controll whether it's SS or SC. When -m is not > used, then it's one process per connection thus CS. > > Is this correct? Basically, yes. The question is what to do if the config options conflict with the running mode. There was a suggestion to adjust the -m setting dynamically, depending on the SharedDatabase option. It counds suitable at the first glance. However, I foresee some issues if someones explicitly installs "SuperServer" but it actually runs as "Classic", or vice versa :-) Dmitry |
From: Dmitry Y. <fir...@ya...> - 2012-03-22 09:12:59
|
22.03.2012 13:00, Thomas Steinmaurer wrote: > * Under the assumption that SS as a single-process model with it's > shared cache supports SMP (I think this was a primarly goal) in 3.0 like > SC in 2.5, I don't see a reason to offer SC in 3.0 at all (at least the > SC terminology; which already shows up in the missing SC part in "instsvc")? Personally, I agree. But we need to hear other opinions as well. > * Or are there any benefits running a non-shared cache single-process > model against the shared cache counterpart? A shared cache model IMHO > offers a more predictable way for system operations from a page cache > (RAM) usage POV It would depend on how good the new SS handles the scalability with different cache sizes. > * Unlike InterBase customers, I guess Classic won't be abonded, cause > current Firebird customers still want the per-connection fail-resistant > sandbox behaviour Correct. > * How does Embedded 3.0 fit in here? SS still with the shared database > option? firebird.conf dictates the rules here. SharedDatabase should depend exclusively on whether you need multiple application accessing the database or not. SharedCache should be ideally always on, but currently the SharedDatabase+SharedCache mode is not reliable and it has very questionable performance benefits (if any), so perhaps SharedCache should depend on your SharedDatabase choice. Dmitry |
From: Alex P. <pes...@ma...> - 2012-03-22 10:18:52
|
On 03/22/12 13:13, Dmitry Yemanov wrote: > 22.03.2012 13:00, Thomas Steinmaurer wrote: > >> * Under the assumption that SS as a single-process model with it's >> shared cache supports SMP (I think this was a primarly goal) in 3.0 like >> SC in 2.5, I don't see a reason to offer SC in 3.0 at all (at least the >> SC terminology; which already shows up in the missing SC part in "instsvc")? > Personally, I agree. But we need to hear other opinions as well. > There may exist various configurations. Specially with per-database selectable mode of operation. For example, we have 2 databases, one big and used in SS mode, another relatively small, but it must be accessed by WWW server. The fastest way for it is embedded access, but sometimes we need to update information in that database too (typically pass something from main database). Making it superclassic can be ideal in this case. We anyway have single process executing all network requests which works in shared cache (SS) mode with first database, but can also access second database as classic one. Page cache for main process (WWW), accessing second database, can be done big enough. |
From: Alex P. <pes...@ma...> - 2012-03-22 08:34:14
|
On 03/22/12 12:22, Dmitry Yemanov wrote: > 22.03.2012 12:06, Alex Peshkoff wrote: > >> From command line switches POV there is no difference in FB3 between SS >> and SC - they both are 'single process serving multiple connections'. >> But if instsvc does not support -m, you can't install SS too. > You can, as it still has options "superserver" and "classic". The former > one implicitly adds the -m switch behind the scenes. > > In order to set it up as SuperClassic, you need to install it as "super" > and change firebird.conf appropriately. Probably small change in help text - SS or SC - will be useful. |
From: Dmitry Y. <fir...@ya...> - 2012-03-22 08:42:21
|
22.03.2012 12:34, Alex Peshkoff wrote: > Probably small change in help text - SS or SC - will be useful. Before doing that, we need to decide whether the former SuperClassic will be the documented option or just some "internal" stuff for easier debugging etc, as FB3 is intended to make it mostly obsolete. Dmitry |
From: Alex P. <pes...@ma...> - 2012-03-22 08:44:09
|
On 03/22/12 12:29, Thomas Steinmaurer wrote: > => Does that mean: We have a single executable in Firebird 3. When -m is > used, this means a single server process and the SharedCache, > SharedDatabase parameters controll whether it's SS or SC. When -m is not > used, then it's one process per connection thus CS. > > Is this correct? Yes. BTW, in posix things are even more funny. "firebird" executable detects, is it started from shell (SS/SC) or from (x)inetd network listener (CS). Therefore no switch "-m" is needed at all. |
From: Thomas S. <ts...@ib...> - 2012-03-22 09:00:47
|
>> => Does that mean: We have a single executable in Firebird 3. When -m is >> used, this means a single server process and the SharedCache, >> SharedDatabase parameters controll whether it's SS or SC. When -m is not >> used, then it's one process per connection thus CS. >> >> Is this correct? > > Basically, yes. > > The question is what to do if the config options conflict with the > running mode. There was a suggestion to adjust the -m setting > dynamically, depending on the SharedDatabase option. It counds suitable > at the first glance. However, I foresee some issues if someones > explicitly installs "SuperServer" but it actually runs as "Classic", or > vice versa :-) Whenever there are options, things can get confusing. ;-) I possibly overstress that area, so I'm sorry to continue the discussion ... *g* * Under the assumption that SS as a single-process model with it's shared cache supports SMP (I think this was a primarly goal) in 3.0 like SC in 2.5, I don't see a reason to offer SC in 3.0 at all (at least the SC terminology; which already shows up in the missing SC part in "instsvc")? * Or are there any benefits running a non-shared cache single-process model against the shared cache counterpart? A shared cache model IMHO offers a more predictable way for system operations from a page cache (RAM) usage POV * Unlike InterBase customers, I guess Classic won't be abonded, cause current Firebird customers still want the per-connection fail-resistant sandbox behaviour * How does Embedded 3.0 fit in here? SS still with the shared database option? Regards, Thomas |
From: philippe m. <pma...@ib...> - 2012-03-22 09:48:35
|
Alex Peshkoff [2012-03-22 09:43] : > BTW, in posix things are even more funny. "firebird" executable detects, > is it started from shell (SS/SC) or from (x)inetd network listener (CS). > Therefore no switch "-m" is needed at all. and in that case, what about systemd, where xinetd is no longer something need ? here systemd scripts for Classic : file firebird-classic.socket: [Unit] Description=Firebird Classic Activation Socket [Socket] ListenStream=3050 Accept=true [Install] WantedBy=sockets.target file firebird-classic@.service: [Unit] Description=Firebird Classic server After=local-fs.target [Service] User=firebird Group=firebird ExecStart=/usr/sbin/fb_inet_server StandardInput=socket StandardError=syslog and to start it : systemctl start firebird-classic.socket |
From: Alex P. <pes...@ma...> - 2012-03-22 10:20:30
|
On 03/22/12 13:48, philippe makowski wrote: > Alex Peshkoff [2012-03-22 09:43] : >> BTW, in posix things are even more funny. "firebird" executable detects, >> is it started from shell (SS/SC) or from (x)inetd network listener (CS). >> Therefore no switch "-m" is needed at all. > and in that case, what about systemd, where xinetd is no longer > something need ? > > here systemd scripts for Classic : > ............... > StandardInput=socket Here is an answer. If stdin is a socket, firebird server runs in classic mode. |