Re: [firebird-support] Typo in Firebird Butler announcement
The typo still persists in the following links: http://ibphoenix.com/ https://www.firebirdnews.org/ https://www.firebirdnews.org/introducing-firebird-butler/ Thanks. Em 01/02/2019 04:46, valdir.mar...@ig.com.br [firebird-support] escreveu: > There is a typo in: > https://firebirdsql.org/en/start/ > > and: > https://firebirdsql.org/en/news/introducing-firebird-butler/ > > "alongside the core (Fierbird database system) and database drivers." > > There is a "FiERbird" instead of "FiREbird." > > Thanks. > Links: -- [1] https://groups.yahoo.com/neo/groups/firebird-support/conversations/messages/133617;_ylc=X3oDMTJybTc4b3FlBF9TAzk3MzU5NzE0BGdycElkAzI0NDI0MDYEZ3Jwc3BJZAMxNzA1MTE1Mzg2BG1zZ0lkAzEzMzYxNwRzZWMDZnRyBHNsawNycGx5BHN0aW1lAzE1NDkwMDM1ODk-?act=replymessageNum=133617 [2] https://groups.yahoo.com/neo/groups/firebird-support/conversations/newtopic;_ylc=X3oDMTJlZXBuaGgyBF9TAzk3MzU5NzE0BGdycElkAzI0NDI0MDYEZ3Jwc3BJZAMxNzA1MTE1Mzg2BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTU0OTAwMzU4OQ-- [3] https://groups.yahoo.com/neo/groups/firebird-support/conversations/topics/133617;_ylc=X3oDMTM4OWxnYTk0BF9TAzk3MzU5NzE0BGdycElkAzI0NDI0MDYEZ3Jwc3BJZAMxNzA1MTE1Mzg2BG1zZ0lkAzEzMzYxNwRzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzE1NDkwMDM1ODkEdHBjSWQDMTMzNjE3 [4] https://yho.com/1wwmgg [5] http://www.firebirdsql.org [6] http://www.ibphoenix.com/resources/documents/ [7] https://groups.yahoo.com/neo/groups/firebird-support/info;_ylc=X3oDMTJlcG11b2Y4BF9TAzk3MzU5NzE0BGdycElkAzI0NDI0MDYEZ3Jwc3BJZAMxNzA1MTE1Mzg2BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTU0OTAwMzU4OQ-- [8] https://groups.yahoo.com/neo;_ylc=X3oDMTJkOGtra2M2BF9TAzk3MzU5NzE0BGdycElkAzI0NDI0MDYEZ3Jwc3BJZAMxNzA1MTE1Mzg2BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNTQ5MDAzNTg5 [9] https://info.yahoo.com/privacy/us/yahoo/groups/details.html [10] https://info.yahoo.com/legal/us/yahoo/utos/terms/
ODP: [firebird-support] Question about delay in fetch operation
Yes, this wideo is usefull and show where the problem is. 1. Something is not satisfy by ypour filter and go throught 1M rows when you have this one additional record vs 21K. 2. First run go from disk – 59K reads from disk vs 2.5K. Look about your where clause and also if your inner join catch whole index segments (explained plan can help here). Also increase cache of this database. Regards, Karol Bieniaszewski
[firebird-support] Re: Question about delay in fetch operation
From the video you made: a) when you fetch 4791 records there are more then 1M record reads at 3 tables (HD_STATUS, etc) (0:58 at video) b) when you fetch 4790 records there are just 21K record reads at same 3 tables (HD_STATUS, etc) (1:32 at video) I.e. there is a lot of records in one of that 3 tables which have no corresponding records at other tables to join. No wonder it need more time to read >1M records than 21K records Regards, Vlad
Re: ODP: ODP: [firebird-support] Re: Introducing Firebird Butler
Hi, Dne 01. 02. 19 v 14:10 Karol Bieniaszewski liviusliv...@poczta.onet.pl [firebird-support] napsal(a): >>> You completely misunderstood the announcement. The Firebird Butler is a >>> thing that we develop. > > I am really interested if i am only one And because of this i am talking > about any example as a first steep. Well, if you read the list of services we plan to develop in first round, you can imagine in how many ways they could be assembled together to achieve various results. The point is, that Butler platform should allow you to assemble them to work in single executable process, or in set of separate processes that could be even distributed over multiple nodes. The "container wrapping" should allow full customization. How exactly these services would be created (features etc.) is not yet determined. We certainly have our own plans and ideas, but we deliberately opened the project before this was "carved in stone", so others could get involved early with their own ideas and needs (so forks or alternative versions are less likely to appear, as we don't want to fragment the ecosystem from start). If you want at least one real world use case, then imagine that you have 1000+ pharmacy shops and several HQ's in 5 countries with your applications and Firebird servers & databases you have to manage (backups, performance monitoring, failure detection & recovery, including hw monitoring & management etc.). Picture yourself you have to deal with such system 24x7. Then answer to yourself what you would need to sleep tight at night? We (IBPhoenix) think that Butler would help us and our customers sleep well. But Butler is not just for big IT systems, it's designed to be equally usable for small and personal solutions as well. Why do you think we put so much importance to allow creation of single-process Butler apps in our architecture? To allow easily deplorable custom builds/assemblies for specific small and personal use. But our (IBPhoenix) personal interests are more at the high end. >>> Steam-like deployment platform for Butler services provided by Firebird > > Ok, than is this as a distribution platform for „small” services or what? Personally (as Python Butler SDK lead developer), I would like create a deployment platform for Butler services that would allow users to download and install Python Butler services from shared repository and run them in custom configured containers. We could then have deployment "recipes" tailored for specific tasks that would download, install, configure and run services, instead having specifically tailored binary distributions. If you are familiar with Python, then picture something like PyPI & pip + paste combined. I don't know what plans exactly others have with their versions (Java, Pascal), we will see what they come with. Eventually the Firebird Project would like to host a repository of Butler services for direct deployment for all "language kits". But that is more distant future. After all, Python, Java and Pascal have very different distribution & deployment methods. However, the point is that services created in different languages can work together as they are. Any deployment or integration "platform" is just nice simplification of deployment that could be always done by hand. >>> So far, there is no single line of code available to public that you > could use > > Do you think that this was too early announced especially on support group > then? > Normally i am real enthusiast of „new” ideas especially in products which i > use, but without exaple hmm... Well, firebird-support list is one from most visited Firebird communication channels. We thought that such announcement is worth to send here as well. >>> But either REST or Widnows services are NOT good enough for IBPhoenix >>> purposes > > Can you extend this sentence, especially why? > What is in this planning „Butler” what is better? > This description can bring more light on the purpose. Well, do you think... - that http is best and most efficient method of communication between services, especially between ones that may live also in the same executable / process? We need "elastic" effectivity, i.e. squeeze as much as possible from each specific deployment environment and scenario. - that http+REST is good for asynchronous communication between services? We need async, sync would be nice sometimes but not essential. - that REST API is more message oriented than interface oriented? Our experience is that interface oriented approach while easier to cope with is a show killer in too many situations. - that REST API is easy and most effective way how to assemble multiple services together in any non-trivial manner without extensive custom glue code? We want to avoid glue code as much as possible, declarative approach is better for us, especially when dealing with 100+ copies of the similar yet not exactly the same. - that Windows
[firebird-support] Question about delay in fetch operation
Hello. Since the topic died down I would like to give it another go and explain all that transpired, in the hopes of trying to understand this behavior. I am unable to determine is this is normal/intended behavior, or something that might be worth being looked upon by the devs. -I have a query that returns 4791 results. There are no row limit on the query. -There is automated daily maintenance on this database, we run both GC and fully recompute selectivity of indices every day. -The fetch operation is very fast until it reaches record number 4000, then it hangs for 20-30 seconds, and resumes the fetch normally. -I tried identifying and removing the record in question, but the problem persisted (the new row 4000 of the fetch hanged after I deleted the old row). -If I limit the query to 4790 results (or less), the entire fetch runs fast, no hang-ups. -Trying deleting the last few records because of this, both behavior remained unchanged (hangs at record 4000 if query is without limit, runs fast if query is limited by 1 or more rows from the total). -Ran those tests trough 3 different applications : isql, raw php and ibexpert, the behavior is consistent among all. This happened in firebird 3.0.4, embedded and remotely. I copied the db over and reproduced the same behavior in 2 different servers successfully, to eliminate the hardware from the equation. Now, in the last few days, I created 2 new databases, one in firebird 2.5 and another in 3.0, and copied over all the structure and data from the original db, I wanted to test the behavior in a raw new database with zeroed usage statistics, and on the older firebird 2.5. Was also able to reproduce the same behavior in both of these new databases.. I recorded a video of the behavior from ibexpert here http://cb.multidadosti.com.br/plaenge.mp4 Again, Im sorry if Im missing something and there might be a logical explanation for this happening.
ODP: ODP: [firebird-support] Re: Introducing Firebird Butler
>>You completely misunderstood the announcement. The Firebird Butler is a >>thing that we develop. I am really interested if i am only one And because of this i am talking about any example as a first steep. >> Steam-like deployment platform for Butler services provided by Firebird Ok, than is this as a distribution platform for „small” services or what? >> So far, there is no single line of code available to public that you could use Do you think that this was too early announced especially on support group then? Normally i am real enthusiast of „new” ideas especially in products which i use, but without exaple hmm... >> But either REST or Widnows services are NOT good enough for IBPhoenix >> purposes Can you extend this sentence, especially why? What is in this planning „Butler” what is better? This description can bring more light on the purpose. regards, Karol Bieniaszewski
Re: ODP: [firebird-support] Re: Introducing Firebird Butler
Hi, Dne 01. 02. 19 v 8:04 Karol Bieniaszewski liviusliv...@poczta.onet.pl [firebird-support] napsal(a): > > If you or someone can show me (and maybe others are also interested) any real > benefit, example, than i am more than interested in this. > And i am not only interested in using it, but i then can offer time to > implement something. You completely misunderstood the announcement. The Firebird Butler is a thing that we develop. It's a joined effort primarily driven by IBPhoenix and IBSurgeon as part of Firebird Project (these companies are currently the main drivers, but others are welcome) initiated by their internal need and in scope of mutual interests with Firebird Project they are part of. It's done as open source so everyone could benefit from our joined effort, but it's not developed for our or public entertainment or without business angle that makes sense for those involved. It's designed as it's designed because it makes sense for those involved, it solves (or should solve) problems they face. So far, there is no single line of code available to public that you could use. Although IBPhoenix (and IBSurgeon as well) has wagons of various internal tools and code for many Firebird-related and other purposes, they are not (yet) adapted to Butler architecture. Anyway we have a neat pool of code and proven ideas to draw from to move forward quickly once the SDK(s) would be ready. Anyone is welcome to watch what we will do (the easiest way is to sign-up for Butler list(s), and watch Butler web and git repositories). If you will see a value in what we will do, you are free to use it, or join our effort if you want to have an influence on where its going. Also, new ideas and questions are welcome at appropriate place and in proper form. Usual open source business. However, at current state of affairs, it's a time for architects and designers who see potential in our selected approach and would like to participate on such thing to step in and share ideas at Butler list. Once first SDK would be ready, no much space would be left to introduce completely new ideas or designs (that one would like to try or needs) to see it implemented. Once SDK(s) would be ready, anyone is welcome to play with it to see how it could be used for their own purposes. That same apply when first services we have in our plan would be provided. However, if anyone wants to have something we plan to do earlier or to have influence what would be implemented and how, the best option is to get involved in a way and to the extent that would suit their needs. I.e. open source business as usual. > But without real introduction i will stay with REST/Windows services based on > Delphi. > Thay work for me for e.g. IOT with big traffic and any problems. You are welcome to use whatever you see fit for your purposes. But either REST or Widnows services are NOT good enough for IBPhoenix purposes (I could not speak for others). best regards Pavel Cisar IBPhoenix
Re: [firebird-support] Re: Introducing Firebird Butler
Hi, Dne 31. 01. 19 v 20:54 blackfalconsoftw...@outlook.com [firebird-support] napsal(a): > II... > My understanding of the Firebird Butler project could be two-fold... > A specification for best practices for developing distributed systems using > the Firebird Database Engine A set of enterprise tools to implement such > systems (ie: an equivalent to Windows Communication Foundtaion: hence the > attribution to ZeroMQ Just my thoughts... Well, one could call a Framework as "best practices" enforcement tool :-) Although Butler SDK is not a typical framework. If you would draw a parallel to WWW, then Butler specifications are like HTTP and related specifications, Butler SDK's are frameworks and libraries to create services that use these specifications (like there are ones for www technologies), and Butler itself (the product(s)) are applications assembled from these services like web servers, browsers etc. Because it's a LEGO system, it's not a single application, but rather a "distribution" (in Linux sense) or a "delivery platform" (like Steam). Both approaches are possible. Over time, we would like get to the Steam-like deployment platform for Butler services provided by Firebird Project as preferred over purpose-tailored distributions, but it's an open ecosystem, so anyone could do what they want regardless to our preferences. The Firebird Project will create services needed to manage Firebird server deployments (as first goal for Butler product, see description of our plan), but we will not stop there (for example we plan to recreate our internal QA test system as Butler app [set of QA services]). Others could use Butler specifications and SDK's to integrate their applications with services provided by us or other entities as they see fit, or could use Butler applications provided by us and others "as is". Or create their own services/applications for whatever purpose, even not related to Firebird in any way. Does it make more sense now? best regards Pavel Cisar IBPhoenix
Re: [firebird-support] Re: Introducing Firebird Butler
Hi, Dne 31. 01. 19 v 21:05 blackfalconsoftw...@outlook.com [firebird-support] napsal(a): > > Has anyone considered using ZeroC's Ice Framework? Ice is classic RPC framework with all its limits and drawbacks. We think that RPC is wrong abstraction model to create dynamic heterogeneous systems. The abstraction model of our choice is pure message passing between "objects" (services), not interfaces, hence the reason we chose ZeroMQ. > It appears to be a much more finished product with better diocumentation > than ZeroMQ and is completely Open Source... ZeroMQ is not less "finished" than Ice, it's also open source and documentation is quite solid (although not that fancy). The differences is "quality" you percept are caused by fact that Ice is "corporate open source", while ZeroMQ is "community open source". In this regard you could say that MySQL is more finished product with better documentation than Firebird. best regards Pavel Cisar IBPhoenix
