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
> 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
>>> 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:
>
>>
> 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
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
> > 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
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).
>
>"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
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
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
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
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" ->
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
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
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
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
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
>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
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
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
Now you're being overly dramatic. Firebird works without configuration.
Mark
- Bericht beantwoorden -
Van: "Dimitry Sibiryakov" <s...@ibphoenix.com>
Aan: "For discussion among Firebird Developers"
<firebird-devel@lists.sourceforge.net>
Onderwe
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
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.
>
>
-
Van: "Michal Kubecek" <m...@mk-sys.cz>
Aan: "For discussion among Firebird Developers"
<firebird-devel@lists.sourceforge.net>
Onderwerp: [Firebird-devel] Performance of fbclient.dll of recent snapshots
Datum: di, apr. 26, 2016 18:58
On Tue, Apr 26, 2016 at 05:5
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
>
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
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
>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
>
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
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
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
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
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
> 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
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.
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
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
>>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
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
> 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
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
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
> 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
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)
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
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
> >
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
> 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 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
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.dll
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
67 matches
Mail list logo
