On Wed, May 04, 2016 at 04:01:10PM +0200, Stefan Heymann wrote:
> > Ok, that did the trick. I can now also confirm that connecting to a
> > Firebird 2.5 server is quick when IPv6 is inactive on localhost.
>
> Now that the technical reasons for this one-second delay are
> clarified: is there someth
> Ok, that did the trick. I can now also confirm that connecting to a
> Firebird 2.5 server is quick when IPv6 is inactive on localhost.
Now that the technical reasons for this one-second delay are
clarified: is there something that can/will be done to improve the
situation? Do I need to open a ti
>>> I can confirm that: using a 3.0 fbclient to connect to a *remote* 2.5
>>> server is quick. The problem seems to be related to the local machine
>>> (I didn't manage to switch IPv6 off for my localhost on Windows).
>
>>Just add (uncomment) following line at System32\drivers\etc\hosts:
>
>> 1
> Sean, can you confirm that there is no delay when using 3.0 fbclient
> with remote 2.5 server?
I can confirm that: using a 3.0 fbclient to connect to a *remote* 2.5
server is quick. The problem seems to be related to the local machine
(I didn't manage to switch IPv6 off for my localhost on Windo
28.04.2016 18:48, Stefan Heymann wrote:
>> Sean, can you confirm that there is no delay when using 3.0 fbclient
>> with remote 2.5 server?
>
> I can confirm that: using a 3.0 fbclient to connect to a *remote* 2.5
> server is quick. The problem seems to be related to the local machine
> (I didn't ma
> > Unfortunately, this function available in server OS starting with
> > Win2003 but is only available on client OS as of Win8.1 (the page
> > awkwardly refers to Vista support -- which would imply Win7+)
>
> Vista and up are supported(maybe some XP versions, but I think Microsoft
> removed tho
Hi,
At April 27, 2016, 1:16 PM, Leyne, Sean wrote:
> That is likely why MS introduced WSAConnectByList function, which
> returns a connection for the first available hosts based on IP
> address list (both IPv4 and IPv6 addresses).
> (https://msdn.microsoft.com/en-us/library/windows/desktop/ms741
On Wed, Apr 27, 2016 at 04:48:53PM +0200, Dimitry Sibiryakov wrote:
>Quoting RFC 6724:
>
> >Well-behaved applications SHOULD NOT simply use the first address
> >returned from an API such as getaddrinfo() and then give up if it
> >fails. For many applications, it is appropriate to
>"Solutions" that only shift the problem into less visited area or drop the
> problem to users is not a way to go.
>
>Quoting RFC 6724:
>
> >Well-behaved applications SHOULD NOT simply use the first address
> >returned from an API such as getaddrinfo() and then give up if it
> >
> Sean, can you confirm that there is no delay when using 3.0 fbclient with
> remote 2.5 server?
I don't have that config available, perhaps Stefan can try and report back.
Sean
--
Find and fix application performance
On Wed, Apr 27, 2016 at 03:42:16PM +0200, Dimitry Sibiryakov wrote:
> 27.04.2016 15:33, Michal Kubecek wrote:
> > After a one second timeout, apparently. And that's exactly where the
> > problem is.
>
> And the most reliable solution for the problem is to try other
> addresses without waiting for
27.04.2016 16:31, Michal Kubecek wrote:
> I already explained why this_workaround_ is wrong - and what the
> _solution_ is.
"Solutions" that only shift the problem into less visited area or drop the
problem to
users is not a way to go.
Quoting RFC 6724:
>Well-behaved applications S
27.04.2016 15:33, Michal Kubecek wrote:
> After a one second timeout, apparently. And that's exactly where the
> problem is.
And the most reliable solution for the problem is to try other addresses
without
waiting for timeout error from the first one. All the rest will fail under some
circum
On Wed, Apr 27, 2016 at 03:24:28PM +0200, Dimitry Sibiryakov wrote:
> 27.04.2016 15:08, Michal Kubecek wrote:
> > The problem is in local system setup; first it tells the client
> > where to connect and then it hides the fact that the connection didn't
> > succeed. That's plain wrong.
>
> Use only
On Wed, Apr 27, 2016 at 09:57:36AM -0300, Adriano dos Santos Fernandes wrote:
> >
> Firebird is not probably (I think) the unique application in the world
> connecting via tcp (ipv4 or ipv6) to things. Or is it?
Definitely not.
> Is the problem happening with other applications and how they are
>
27.04.2016 15:08, Michal Kubecek wrote:
> The problem is in local system setup; first it tells the client
> where to connect and then it hides the fact that the connection didn't
> succeed. That's plain wrong.
Use only first structure returned by getaddrinfo() and you'll get your error.
--
On Wed, Apr 27, 2016 at 02:54:11PM +0200, Dimitry Sibiryakov wrote:
> 27.04.2016 11:27, Michal Kubecek wrote:
> > Please stop pretending the problem is way worse than it actually is.
>
> It is enough that the problem exists and can be solved without tuning
> of global OS settings.
"solve" -> "wor
On 27/04/2016 09:54, Dimitry Sibiryakov wrote:
> 27.04.2016 11:27, Michal Kubecek wrote:
>> Please stop pretending the problem is way worse than it actually is.
>It is enough that the problem exists and can be solved without tuning of
> global OS
> settings.
>
> PS: I wonder why Vlad still ha
27.04.2016 11:27, Michal Kubecek wrote:
> Please stop pretending the problem is way worse than it actually is.
It is enough that the problem exists and can be solved without tuning of
global OS
settings.
PS: I wonder why Vlad still hasn't demanded to rollback the path completely and
immedia
27.04.2016 0:11, Leyne, Sean wrote:
> 2- Slowness only occurs when using "localhost" with v3 client and v2.5
> server -- a very unusual situation (why would you have new client installed
> on same host as old server?)
No, this problem will occur on any host with multiple IP addresses when
F
On Wed, Apr 27, 2016 at 11:03:33AM +0200, Dimitry Sibiryakov wrote:
> 27.04.2016 0:11, Leyne, Sean wrote:
> > 2- Slowness only occurs when using "localhost" with v3 client*and* v2.5
> > server -- a very unusual situation (why would you have new client installed
> > on same host as old server?)
27.04.2016 0:11, Leyne, Sean wrote:
> 2- Slowness only occurs when using "localhost" with v3 client*and* v2.5
> server -- a very unusual situation (why would you have new client installed
> on same host as old server?)
No, this problem occur on any host with multiple IP addresses when Fireb
27.04.2016 01:11, Leyne, Sean пишет:
>
>> To let rumors that Firebird is unbearable slow to spread is a bad thing
>> too.
> 1- 1 sec is not "unbearable"!
>
> 2- Slowness only occurs when using "localhost" with v3 client *and* v2.5
> server -- a very unusual situation (why would you have n
>To let rumors that Firebird is unbearable slow to spread is a bad thing
> too.
1- 1 sec is not "unbearable"!
2- Slowness only occurs when using "localhost" with v3 client *and* v2.5
server -- a very unusual situation (why would you have new client installed on
same host as old server?
Stefan,
> The problem is when I use the Fb3 client to connect to a Fb2.5 database.
> Then there is this one second delay.
>
> To sum things up:
>
> Connection time using the new Fb3 fbclient.dll:
> - 3.0 database using "localhost" - quick
> - 3.0 database using "127.0.0.1" - quick
> - 2.5 databa
26.04.2016 22:40, Mark Rotteveel wrote:
> Firebird works without configuration.
To let rumors that Firebird is unbearable slow to spread is a bad thing too.
--
WBR, SD.
--
Find and fix application performance issu
Now you're being overly dramatic. Firebird works without configuration.
Mark
- Bericht beantwoorden -
Van: "Dimitry Sibiryakov"
Aan: "For discussion among Firebird Developers"
Onderwerp: [Firebird-devel] Performance of fbclient.dll of recent snapshots
Datum
26.04.2016 22:03, Michal Kubecek wrote:
> But now I'm starting to worry that any
> solution that is not handling his corner case out of the box without
> waiting for a timeout is not going to satisfy him.
Any solution that requires a special configuration of host OS in order to
make Firebird
On Tue, Apr 26, 2016 at 09:56:30PM +0200, Michal Kubecek wrote:
> On Tue, Apr 26, 2016 at 07:02:48PM +0200, Dimitry Sibiryakov wrote:
> > 26.04.2016 18:58, Michal Kubecek wrote:
> > > Disabling it unconditionally is not a good idea. Perhaps it could be
> > > controlled via firebird.conf but I would
On Tue, Apr 26, 2016 at 08:06:22PM +0200, Mark Rotteveel wrote:
> Or you use netsh (on windows) to change the precedence
> (prefixpolicies) of using ipv4 or ipv6 for a specific subnet, or
> /etc/gai.conf on Linux.
>
> A lot simpler than not having ipv6 for a host just because you use a
> new clien
26.04.2016 21:56, Michal Kubecek wrote:
> That doesn't make much sense to me. Actually one of my long term plans
> is to refactor struct rem_port into a hierarchy of classes. But I don't
> see much benefit in providing support for different protocols in the
> form of plugins.
But that's exactly
On Tue, Apr 26, 2016 at 07:02:48PM +0200, Dimitry Sibiryakov wrote:
> 26.04.2016 18:58, Michal Kubecek wrote:
> > Disabling it unconditionally is not a good idea. Perhaps it could be
> > controlled via firebird.conf but I would still prefer the connection
> > string as more flexible.
>
>Extrac
-
Van: "Michal Kubecek"
Aan: "For discussion among Firebird Developers"
Onderwerp: [Firebird-devel] Performance of fbclient.dll of recent snapshots
Datum: di, apr. 26, 2016 18:58
On Tue, Apr 26, 2016 at 05:57:19PM +0200, Dimitry Sibiryakov wrote:
> 26.04.2016 17:48, Stefa
26.04.2016 18:58, Michal Kubecek wrote:
> Disabling it unconditionally is not a good idea. Perhaps it could be
> controlled via firebird.conf but I would still prefer the connection
> string as more flexible.
Extract IPv6 support from remote to a separate plugin.
--
WBR, SD.
-
On Tue, Apr 26, 2016 at 05:57:19PM +0200, Dimitry Sibiryakov wrote:
> 26.04.2016 17:48, Stefan Heymann wrote:
> > we need the URL type db string
> > solution described by Michael so only IPv4 gets tried by the client.
>
> This solution requires to change every connection string in every
> applicat
26.04.2016 17:48, Stefan Heymann wrote:
> we need the URL type db string
> solution described by Michael so only IPv4 gets tried by the client.
This solution requires to change every connection string in every
application worked
with Firebird which is often hard-coded.
Disabling IPv6 in cl
26.04.2016 17:48, Stefan Heymann wrote:
> Situation Nr. 1 is a pre-Firebird3 server.
No, it is number 2. Number 1 is no Firebird at all.
--
WBR, SD.
--
Find and fix application performance issues faster with Appli
>If a server has both IPv4 and IPv6 addresses, there can be four cases:
> 1) Firebird doesn't listen on both of them
> 2) Firebird listens on IPv4 only
> 3) Firebird listens on IPv6 only
> 4) Firebird listens on both
>Whatever priority you set up, in one case of four you'll get slow
> co
If a server has both IPv4 and IPv6 addresses, there can be four cases:
1) Firebird doesn't listen on both of them
2) Firebird listens on IPv4 only
3) Firebird listens on IPv6 only
4) Firebird listens on both
Whatever priority you set up, in one case of four you'll get slow connection.
--
26.04.2016 13:25, Michal Kubecek wrote:
> That's completely different situation. With bittorrent, you want to
> access all targets, not one of them
Yes, but it is a good example how to work with a swarm of unreliable
servers. Exactly
matches situation in this topic where connection must be es
26.04.2016 14:12, Michal Kubecek wrote:
> On Tue, Apr 26, 2016 at 12:05:44PM +0200, Dimitry Sibiryakov wrote:
>> 26.04.2016 12:01, Stefan Heymann wrote:
>>> So I think Michael's idea to expand the URL type database strings is a
>>> good idea:
>>
>> No, it is just a workaround.
>> Good solution will
On Tue, Apr 26, 2016 at 01:16:17PM +0200, Dimitry Sibiryakov wrote:
> 26.04.2016 13:12, Michal Kubecek wrote:
> > Are you aware of other client applications doing this for TCP based
> > protocols?
>
>Any torrent client.
That's completely different situation. With bittorrent, you want to
acces
26.04.2016 13:12, Michal Kubecek wrote:
> Are you aware of other client applications doing this for TCP based
> protocols?
Any torrent client.
--
WBR, SD.
--
Find and fix application performance issues faster with
On Tue, Apr 26, 2016 at 12:05:44PM +0200, Dimitry Sibiryakov wrote:
> 26.04.2016 12:01, Stefan Heymann wrote:
> > So I think Michael's idea to expand the URL type database strings is a
> > good idea:
>
> No, it is just a workaround.
> Good solution will be to connect to all host addresses at once
26.04.2016 12:44, Stefan Heymann wrote:
> Is there a chance that one of them will be
> implemented?
I have in plans to implement parallel connect in v4 as a part of cluster
solution.
--
WBR, SD.
--
Find and fix a
> 26.04.2016 12:01, Stefan Heymann wrote:
>> So I think Michael's idea to expand the URL type database strings is a
>> good idea:
>No, it is just a workaround.
>Good solution will be to connect to all host addresses at once using
> connection that is
> established as a first.
Sounds goo
26.04.2016 12:01, Stefan Heymann wrote:
> So I think Michael's idea to expand the URL type database strings is a
> good idea:
No, it is just a workaround.
Good solution will be to connect to all host addresses at once using
connection that is
established as a first.
--
WBR, SD.
-
> 25.04.2016 22:34, Michal Kubecek wrote:
>> No, that's not the reason. If everything works the way it's supposed to,
>> the connection fails within one roundtrip and client doesn't have to
>> wait for a full second. For :: address, there is even less reason for
>> having to wait for a timeout.
>
25.04.2016 22:34, Michal Kubecek wrote:
> No, that's not the reason. If everything works the way it's supposed to,
> the connection fails within one roundtrip and client doesn't have to
> wait for a full second. For :: address, there is even less reason for
> having to wait for a timeout.
Unles
On Mon, Apr 25, 2016 at 05:46:24PM +0200, Dimitry Sibiryakov wrote:
> 25.04.2016 17:42, Michal Kubecek wrote:
> > A 2.5 server, however, does only listen to IPv4 connections and for
> > some reason, client has to wait for timeout of the connection to ::
> > which is tried first.
>
> Reason is simp
25.04.2016 17:42, Michal Kubecek wrote:
> A 2.5 server, however, does only listen to IPv4 connections and for some
> reason, client has to wait for timeout of the connection to :: which is
> tried first.
Reason is simple: addresses for a host are tried one-by-one.
--
WBR, SD.
On Mon, Apr 25, 2016 at 05:07:13PM +0200, Stefan Heymann wrote:
> >>Try to set option IPv6V6Only to true in firebird.conf and see if
> >>it makes any difference.
>
> > This directive affects only listening sockets (i.e. a server) and
> > would actually do the exact opposite: make the serve
>>Try to set option IPv6V6Only to true in firebird.conf and see if it
>>makes any difference.
> This directive affects only listening sockets (i.e. a server) and would
> actually do the exact opposite: make the server listening on (default)
> address :: accept only IPv6 connections (to any
On Sat, Apr 23, 2016 at 12:13:26PM +0200, Dimitry Sibiryakov wrote:
> 23.04.2016 12:01, Stefan Heymann wrote:
> >> It seems that your problem is due to slow host name to IP address
> >> >resolution (i.e. DNS), not with Firebird functionality.
> > But my 2.5 fbclient does not show this delay. So I d
> Try to set option IPv6V6Only to true in firebird.conf and see if it makes
> any difference.
I copied a firebird.conf from Fb3 to the client folder, changed that
to true (1). There's no difference. Still that second.
Regards
Stefan
--
23.04.2016 12:01, Stefan Heymann wrote:
>> It seems that your problem is due to slow host name to IP address
>> >resolution (i.e. DNS), not with Firebird functionality.
> But my 2.5 fbclient does not show this delay. So I don't assume there
> is a problem with IP resolution.
Try to set option I
23.04.2016 12:01, Stefan Heymann wrote:
> If there is no other solution to come around this problem, I also
> think that this would be easily understandable.
Much simpler will be to disalbe IPV6 support by default.
--
WBR, SD.
--
> It seems that your problem is due to slow host name to IP address
> resolution (i.e. DNS), not with Firebird functionality.
But my 2.5 fbclient does not show this delay. So I don't assume there
is a problem with IP resolution.
> For Windows, the policy table seems to be managed with netsh comma
22.04.2016 18:03, Michal Kubecek wrote:
> We might also consider extending the new connection string format
> inet://... to variants inet4://... and inet6://... which would enforce
> AF_INET or AF_INET6.
This may be a good workaround.
Dmitry
---
Michael,
> For Windows, the policy table seems to be managed with netsh command:
>
> https://technet.microsoft.com/en-
> us/library/cc740203(v=ws.10).aspx#BKMK_5
>
> http://www.colorconsole.de/cmd/en/Windows_Vista/netsh/interface/ipv6/
> add/prefixpolicy.htm
Thanks for the pointers.
But thes
On Fri, Apr 22, 2016 at 08:31:23PM +, Leyne, Sean wrote:
>
> > I don't know what gai.conf is (it's not in my Firebird folder). It should
> > be as
> > easy as possible and as less configuration as possible when we install the
> > software on the servers of our customers.
> >
> > As we still
> I don't know what gai.conf is (it's not in my Firebird folder). It should be
> as
> easy as possible and as less configuration as possible when we install the
> software on the servers of our customers.
>
> As we still mainly live in an IPv4 world (especially in LANs) - would it be
> possible
On 04/22/2016 06:13 PM, Stefan Heymann wrote:
> --- Alex Peshkoff
>
>> Stefan, I've made a test. It's dev-build therefore it's not too fast but
>> look here:
>> [...]
>> I do not notice 3.0 client to work slower.
> Sorry, I forgot to mention that I mean Windows, not Linux.
I might guess myself - .
--- Alex Peshkoff
> Stefan, I've made a test. It's dev-build therefore it's not too fast but
> look here:
> [...]
> I do not notice 3.0 client to work slower.
Sorry, I forgot to mention that I mean Windows, not Linux.
--- Michal Kubecek
> Do you see the same delay when identifying the server b
On 04/22/2016 06:10 PM, Michal Kubecek wrote:
> On Fri, Apr 22, 2016 at 05:53:06PM +0300, Alex Peshkoff wrote:
>> On 04/22/2016 04:59 PM, Stefan Heymann wrote:
>>> I just tested the new 3.0.0 Release (Build 32483) fbclient.dll against
>>> a Firebird 2.5.5 database. It takes ages (about 1 second) to
On Fri, Apr 22, 2016 at 05:53:06PM +0300, Alex Peshkoff wrote:
> On 04/22/2016 04:59 PM, Stefan Heymann wrote:
> > I just tested the new 3.0.0 Release (Build 32483) fbclient.dll against
> > a Firebird 2.5.5 database. It takes ages (about 1 second) to attach to
> > the database. Connection to a Fire
On Fri, Apr 22, 2016 at 03:59:52PM +0200, Stefan Heymann wrote:
> > However, the new fbclient (3.0.0.31529) connecting to old Firebird
> > servers (2.5 and earlier) is also taking 1 second (compared to +/- 25-30
> > milliseconds with Firebird 3 beta 1 fbclient and 15 milliseconds with
> > Firebird
On 04/22/2016 04:59 PM, Stefan Heymann wrote:
>> However, the new fbclient (3.0.0.31529) connecting to old Firebird
>> servers (2.5 and earlier) is also taking 1 second (compared to +/- 25-30
>> milliseconds with Firebird 3 beta 1 fbclient and 15 milliseconds with
>> Firebird 2.5.3 fbclient), so we
> However, the new fbclient (3.0.0.31529) connecting to old Firebird
> servers (2.5 and earlier) is also taking 1 second (compared to +/- 25-30
> milliseconds with Firebird 3 beta 1 fbclient and 15 milliseconds with
> Firebird 2.5.3 fbclient), so we do have a problem.
I just tested the new 3.0.0
On Sun, Jan 04, 2015 at 12:29:56PM +0100, Mark Rotteveel wrote:
>
> So the problem only occurs when a hostname has both an (IPv6) and A
> (IPv4) record. That makes it a little less of a problem, but at minimum
> it should be addressed in the release notes; or maybe fbclient should
> have a
On 4-1-2015 12:13, Alex Peshkoff wrote:
> On 01/04/15 13:59, Mark Rotteveel wrote:
>> On 4-1-2015 11:30, Dmitry Yemanov wrote:
>>> 04.01.2015 13:12, Mark Rotteveel wrote:
>>>
When running with against 3.0.0.31529 server, the performance is better.
An attach takes +/- 45 milliseconds. This
On 01/04/15 13:59, Mark Rotteveel wrote:
> On 4-1-2015 11:30, Dmitry Yemanov wrote:
>> 04.01.2015 13:12, Mark Rotteveel wrote:
>>
>>> When running with against 3.0.0.31529 server, the performance is better.
>>> An attach takes +/- 45 milliseconds. This is still 3x slower than with
>>> the old fbcli
On 4-1-2015 11:30, Dmitry Yemanov wrote:
> 04.01.2015 13:12, Mark Rotteveel wrote:
>
>> When running with against 3.0.0.31529 server, the performance is better.
>> An attach takes +/- 45 milliseconds. This is still 3x slower than with
>> the old fbclient.
>
> Could it be just an Srp vs Legacy auth
04.01.2015 13:12, Mark Rotteveel wrote:
> When running with against 3.0.0.31529 server, the performance is better.
> An attach takes +/- 45 milliseconds. This is still 3x slower than with
> the old fbclient.
Could it be just an Srp vs Legacy auth difference?
Dmitry
---
On 4-1-2015 10:50, Mark Rotteveel wrote:
> I have looked at it closer. The problem seems to be during attach. With
> a 2.5.3 fbclient, it takes +/- 15 milliseconds, with the 3.0.0.31529
> fbclient +/- a second. As it is in attach, it might be related to the
> IPv6 changes. However explicitly specif
On 4-1-2015 09:48, Alex Peshkoff wrote:
> On 12/31/14 18:47, Mark Rotteveel wrote:
>> I was just running a test with the native implementation of Jaybird and
>> the fbclient.dll of todays snapshot (3.0.0.31529-0_x64) is substantially
>> slower than the fbclient.dll of Firebird 3 beta 1 (3.0.0.31374
On 12/31/14 18:47, Mark Rotteveel wrote:
> I was just running a test with the native implementation of Jaybird and
> the fbclient.dll of todays snapshot (3.0.0.31529-0_x64) is substantially
> slower than the fbclient.dll of Firebird 3 beta 1 (3.0.0.31374).
>
> A test run with the snapshot fbclient.
I was just running a test with the native implementation of Jaybird and
the fbclient.dll of todays snapshot (3.0.0.31529-0_x64) is substantially
slower than the fbclient.dll of Firebird 3 beta 1 (3.0.0.31374).
A test run with the snapshot fbclient.dll takes +/- 1 hour, while the
same test run w
78 matches
Mail list logo
