[vwnc] Store performance strategies
Locked
[vwnc] Store performance strategies
 
|
Store access is sluggish when connected to a remote database. It can take several minutes to publish or load code. We've done the Oracle indexing. That helps, but the real problem seems to be
cumulative latency because of how chatty Store is with the RDB (performance inherent to the technology).
I know that Store has near instantaneous response time when working against a local database. I've also heard that some people use a practice of having both a shared dB and local dB to avoid
latency costs.
I'm trying to weigh the benefits of moving to an environment where each developer is configured to use a local Store repository and then publishing/distributing from a shared repository.
Does anyone have any experiences to share?
It seems like the obvious need is to have a process that looks for and imports shared published builds automatically. It isn't clear whether it is best for new
builds to be created in the local repository and then published to the shared repository, or for changes to be moved to the shared and published into new builds there. I assume that parcels are the best transport mechanism and that publishing
a parcel "with database links" is all that is necessary to keep the source pointers correct without creating equal copies in a single dB as the code moves around.
Are there already tools to do this? Perhaps a tool that allows you to select a pundle version or model and "publish to..." another database?
-------
Then there is the dB clone approach:
I presume dB cloning is a batch operation that is not going to be practical for distributed "live" development.
-------
A completely different strategy is to adapt Store by adding a server interface for higher-level operations. In other words, communicate with a server VW image that runs close to the dB rather
than directly communicating with the Store dB. The Store server would be responsible for higher level operations and communicate with objects graphs from multiple queries instead of SQL results from a single query. The graphs could include proxies like stubs
and forwarders.
It seems simple in theory, but no doubt it would be trickier than it looks. It is something that Cincom should implement. The "Store server" could be a feature that commercial customers pay extra
for.
-------
A variation of the last strategy mentioned is to move to an object database where the higher-level operations are root accessors with replication specs to code models in the database. That approach
eliminates the SQL query and object assembly costs but object databases are hardly ubiquitous and standardized--that means either dB vendor lock or a home-built solution.
Paul Baumann
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
The chattiness is not inherent to the technology, or at least it doesn't
have to be nearly as bad as the current implementation. Note for example,
the speed of publish to a remote database using StoreForGlorpVWUI, or the
speed of replication (which uses the same mechanism) relative to
publishing.
Many people within Cincom use this strategy of a local database (and others do not). The truly awful performance and error rate of the network connection I had to the main Cincom database was the motivation for writing the Glorp replicator. It's improved a great deal since then, but I still use a local database for most things. We actually have multiple databases within Cincom that are kept in sync. We run an Oracle and a Postgresql database on the same server (the single biggest motivating factor for that was the lack of Oracle support for Intel Macs) and there's also a SQL Server database used for ObjectStudio. The biggest downside is the overhead of syncing, and the possible time gap between someone publishing and someone else seeing it, especially if you're only doing partial replication, so someone doesn't have something in their list of replication rules, and you have to kick them to add it. But it hasn't been a big deal. At 12:39 PM 2/10/2009, Paul Baumann wrote: Content-Language: en-US --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by Paul Baumann
On 10.02.2009, at 18:39, Paul Baumann wrote: > A completely different strategy is to adapt Store by adding a server > interface for higher-level operations. +1 Not only for higher-level operations. I would like to see the entire Store implementation separated from the development images (OpenTalk STST). Clients should be tiny. Considering todays computing resources, SQL/RDB is an anachronism. Even more so as the task of maintaining source code is rather straightforward and simple, if it only was modeled with objects. Hey, that's what Smalltalk is made for and what it still claims to be its USP. Store is a proprietary solution anyway and its SQL tables are of no use for any other application, so moving it to Smalltalk objects will not loose any functionality or buzz word feature. IMO the contrary is true: A Smalltalk Store implemented entirely in Smalltalk would further add to its credibility. I would expect the Store subsystem to shrink vastly in complexity. Concerning persistence, an object-based implementation would probably also be more easily integrateable with industry standard file-based versioning systems, which would even add another buzz word. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
On 11/02/2009, at 7:48 PM, Andre Schnoor wrote: > Hey, that's what Smalltalk is made for and what it still claims to be > its USP. Store is a proprietary solution anyway and its SQL tables are > of no use for any other application, so moving it to Smalltalk objects > will not loose any functionality or buzz word feature. IMO the > contrary is true: A Smalltalk Store implemented entirely in Smalltalk > would further add to its credibility. I've been getting excited recently about using CouchDB as a source repository for Smalltalk. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things... Whenever his enemies have the ability to attack the innovator, they do so with the passion of partisans, while the others defend him sluggishly, So that the innovator and his party alike are vulnerable. -- Niccolo Machiavelli, 1513, The Prince. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by Andre Schnoor
Interesting, I never received Paul's response that's excerpted here, and it doesn't appear to be my local spam filter that did it. However, he's certainly welcome to do what's described here instead of setting up a replicator :-)
At 04:18 AM 2/11/2009, Andre Schnoor wrote: >On 10.02.2009, at 18:39, Paul Baumann wrote: > >> A completely different strategy is to adapt Store by adding a server >> interface for higher-level operations. > >+1 > >Not only for higher-level operations. I would like to see the entire >Store implementation separated from the development images (OpenTalk >STST). Clients should be tiny. Considering todays computing resources, >SQL/RDB is an anachronism. Even more so as the task of maintaining >source code is rather straightforward and simple, if it only was >modeled with objects. > >Hey, that's what Smalltalk is made for and what it still claims to be >its USP. Store is a proprietary solution anyway and its SQL tables are >of no use for any other application, so moving it to Smalltalk objects >will not loose any functionality or buzz word feature. IMO the >contrary is true: A Smalltalk Store implemented entirely in Smalltalk >would further add to its credibility. > >I would expect the Store subsystem to shrink vastly in complexity. >Concerning persistence, an object-based implementation would probably >also be more easily integrateable with industry standard file-based >versioning systems, which would even add another buzz word. > >Andre > >_______________________________________________ >vwnc mailing list >[hidden email] >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc -- Alan Knight [|], Engineering Manager, Cincom Smalltalk [hidden email] [hidden email] http://www.cincom.com/smalltalk _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by Andre Schnoor
Alan,
That would be fun, but I prioritize work by reward. That work is the domain of a Cincom project. If Cincom had a vast customer base to market to--then perhaps it would get on my list of things to do. Failing a market, improvements like these should the interest of a Cincom development manager...or not, depending on the future desired or legacy safeguarded. Store is very good but it is slower than it could be--a point that you acknowledge. Regards, Paul Baumann -----Original Message----- From: Alan Knight [mailto:[hidden email]] Sent: Wednesday, February 11, 2009 9:32 AM To: Andre Schnoor; Paul Baumann Cc: VWNC Subject: Re: [vwnc] Store performance strategies Importance: High Interesting, I never received Paul's response that's excerpted here, and it doesn't appear to be my local spam filter that did it. However, he's certainly welcome to do what's described here instead of setting up a replicator :-) At 04:18 AM 2/11/2009, Andre Schnoor wrote: >On 10.02.2009, at 18:39, Paul Baumann wrote: > >> A completely different strategy is to adapt Store by adding a server >> interface for higher-level operations. > >+1 > >Not only for higher-level operations. I would like to see the entire >Store implementation separated from the development images (OpenTalk >STST). Clients should be tiny. Considering todays computing resources, >SQL/RDB is an anachronism. Even more so as the task of maintaining >source code is rather straightforward and simple, if it only was >modeled with objects. > >Hey, that's what Smalltalk is made for and what it still claims to be >its USP. Store is a proprietary solution anyway and its SQL tables are >of no use for any other application, so moving it to Smalltalk objects >will not loose any functionality or buzz word feature. IMO the contrary >is true: A Smalltalk Store implemented entirely in Smalltalk would >further add to its credibility. > >I would expect the Store subsystem to shrink vastly in complexity. >Concerning persistence, an object-based implementation would probably >also be more easily integrateable with industry standard file-based >versioning systems, which would even add another buzz word. > >Andre > >_______________________________________________ >vwnc mailing list >[hidden email] >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc -- Alan Knight [|], Engineering Manager, Cincom Smalltalk [hidden email] [hidden email] http://www.cincom.com/smalltalk This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
To play devil's advocate for a moment, bear in mind that a client/
server Store would up the complexity level of using Store by a fair bit. Right now, if you use Postgres, the whole thing is fairly simple If you create a client/server setup, you start running into various issues - -- do I need a separate machine for the server? -- do I have firewall related issues with the server? -- Can I even version code w/o a server? James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On Feb 11, 2009, at 10:19 AM, Paul Baumann wrote: > Alan, > > That would be fun, but I prioritize work by reward. That work is the > domain of a Cincom project. If Cincom had a vast customer base to > market to--then perhaps it would get on my list of things to do. > Failing a market, improvements like these should the interest of a > Cincom development manager...or not, depending on the future desired > or legacy safeguarded. Store is very good but it is slower than it > could be--a point that you acknowledge. > > Regards, > > Paul Baumann > > -----Original Message----- > From: Alan Knight [mailto:[hidden email]] > Sent: Wednesday, February 11, 2009 9:32 AM > To: Andre Schnoor; Paul Baumann > Cc: VWNC > Subject: Re: [vwnc] Store performance strategies > Importance: High > > Interesting, I never received Paul's response that's excerpted here, > and it doesn't appear to be my local spam filter that did it. > However, he's certainly welcome to do what's described here instead > of setting up a replicator :-) > > At 04:18 AM 2/11/2009, Andre Schnoor wrote: > >> On 10.02.2009, at 18:39, Paul Baumann wrote: >> >>> A completely different strategy is to adapt Store by adding a server >>> interface for higher-level operations. >> >> +1 >> >> Not only for higher-level operations. I would like to see the entire >> Store implementation separated from the development images (OpenTalk >> STST). Clients should be tiny. Considering todays computing >> resources, >> SQL/RDB is an anachronism. Even more so as the task of maintaining >> source code is rather straightforward and simple, if it only was >> modeled with objects. >> >> Hey, that's what Smalltalk is made for and what it still claims to be >> its USP. Store is a proprietary solution anyway and its SQL tables >> are >> of no use for any other application, so moving it to Smalltalk >> objects >> will not loose any functionality or buzz word feature. IMO the >> contrary >> is true: A Smalltalk Store implemented entirely in Smalltalk would >> further add to its credibility. >> >> I would expect the Store subsystem to shrink vastly in complexity. >> Concerning persistence, an object-based implementation would probably >> also be more easily integrateable with industry standard file-based >> versioning systems, which would even add another buzz word. >> >> Andre >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > -- > Alan Knight [|], Engineering Manager, Cincom Smalltalk > [hidden email] [hidden email] http://www.cincom.com/smalltalk > > > > This message may contain confidential information and is intended > for specific recipients unless explicitly noted otherwise. If you > have reason to believe you are not an intended recipient of this > message, please delete it and notify the sender. This message may > not represent the opinion of IntercontinentalExchange, Inc. (ICE), > its subsidiaries or affiliates, and does not constitute a contract > or guarantee. Unencrypted electronic mail is not secure and the > recipient of this message is expected to provide safeguards from > viruses and pursue alternate means of communication where privacy or > a binding message is desired. > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by Paul Baumann
Heh. I wasn't really being serious, just trying to point out the obvious answer to the immediate problem and the question that was originally asked.
More speculative ideas about major rewrites of Store are interesting. I don't agree with all of the points mentioned by others, and I still haven't seen yours, but the general idea of having a server protocol rather than direct communication to the database is certainly interesting fromn a number of perspectives. It's not going to be done for 7.7, but something along those lines might happen in a future release. Or might not, I'm not making any promises. At 10:19 AM 2/11/2009, Paul Baumann wrote: >Alan, > >That would be fun, but I prioritize work by reward. That work is the domain of a Cincom project. If Cincom had a vast customer base to market to--then perhaps it would get on my list of things to do. Failing a market, improvements like these should the interest of a Cincom development manager...or not, depending on the future desired or legacy safeguarded. Store is very good but it is slower than it could be--a point that you acknowledge. > >Regards, > >Paul Baumann > >-----Original Message----- >From: Alan Knight [mailto:[hidden email]] >Sent: Wednesday, February 11, 2009 9:32 AM >To: Andre Schnoor; Paul Baumann >Cc: VWNC >Subject: Re: [vwnc] Store performance strategies >Importance: High > >Interesting, I never received Paul's response that's excerpted here, and it doesn't appear to be my local spam filter that did it. However, he's certainly welcome to do what's described here instead of setting up a replicator :-) > >At 04:18 AM 2/11/2009, Andre Schnoor wrote: > >>On 10.02.2009, at 18:39, Paul Baumann wrote: >> >>> A completely different strategy is to adapt Store by adding a server >>> interface for higher-level operations. >> >>+1 >> >>Not only for higher-level operations. I would like to see the entire >>Store implementation separated from the development images (OpenTalk >>STST). Clients should be tiny. Considering todays computing resources, >>SQL/RDB is an anachronism. Even more so as the task of maintaining >>source code is rather straightforward and simple, if it only was >>modeled with objects. >> >>Hey, that's what Smalltalk is made for and what it still claims to be >>its USP. Store is a proprietary solution anyway and its SQL tables are >>of no use for any other application, so moving it to Smalltalk objects >>will not loose any functionality or buzz word feature. IMO the contrary >>is true: A Smalltalk Store implemented entirely in Smalltalk would >>further add to its credibility. >> >>I would expect the Store subsystem to shrink vastly in complexity. >>Concerning persistence, an object-based implementation would probably >>also be more easily integrateable with industry standard file-based >>versioning systems, which would even add another buzz word. >> >>Andre >> >>_______________________________________________ >>vwnc mailing list >>[hidden email] >>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >-- >Alan Knight [|], Engineering Manager, Cincom Smalltalk [hidden email] [hidden email] http://www.cincom.com/smalltalk > > > >This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. -- Alan Knight [|], Engineering Manager, Cincom Smalltalk [hidden email] [hidden email] http://www.cincom.com/smalltalk _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by James Robertson-7
-- do I need a separate machine for the server?
A separate machine would defeat the purpose of avoiding communication latency. -- do I have firewall related issues with the server? Yes, a port would need to be opened. Part of the cost of having the faster server. -- Can I even version code w/o a server? The server can be thought of as a VW image that runs on the same box as the dB and that is available to handle higher-level operations if requested. It would be an optional interface. It would sit on-top-of the exsting store framework. If the server is not running or is too busy then code should fall through to the standard techniques. Are you saying that replacing Oracle with Postgres is all that needs to be done to improve Store performance? I'm not seeing how replacing one RDBMS with another does it--unless you are also talking about special object features of Postgres that would (or could?) be used. That would be great if the solution was so simple. Paul Baumann -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of James Robertson Sent: Wednesday, February 11, 2009 10:37 AM To: VW NC Subject: Re: [vwnc] Store performance strategies To play devil's advocate for a moment, bear in mind that a client/ server Store would up the complexity level of using Store by a fair bit. Right now, if you use Postgres, the whole thing is fairly simple If you create a client/server setup, you start running into various issues - -- do I need a separate machine for the server? -- do I have firewall related issues with the server? -- Can I even version code w/o a server? James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On Feb 11, 2009, at 10:19 AM, Paul Baumann wrote: > Alan, > > That would be fun, but I prioritize work by reward. That work is the > domain of a Cincom project. If Cincom had a vast customer base to > market to--then perhaps it would get on my list of things to do. > Failing a market, improvements like these should the interest of a > Cincom development manager...or not, depending on the future desired > or legacy safeguarded. Store is very good but it is slower than it > could be--a point that you acknowledge. > > Regards, > > Paul Baumann > > -----Original Message----- > From: Alan Knight [mailto:[hidden email]] > Sent: Wednesday, February 11, 2009 9:32 AM > To: Andre Schnoor; Paul Baumann > Cc: VWNC > Subject: Re: [vwnc] Store performance strategies > Importance: High > > Interesting, I never received Paul's response that's excerpted here, > and it doesn't appear to be my local spam filter that did it. > However, he's certainly welcome to do what's described here instead of > setting up a replicator :-) > > At 04:18 AM 2/11/2009, Andre Schnoor wrote: > >> On 10.02.2009, at 18:39, Paul Baumann wrote: >> >>> A completely different strategy is to adapt Store by adding a server >>> interface for higher-level operations. >> >> +1 >> >> Not only for higher-level operations. I would like to see the entire >> Store implementation separated from the development images (OpenTalk >> STST). Clients should be tiny. Considering todays computing >> resources, SQL/RDB is an anachronism. Even more so as the task of >> maintaining source code is rather straightforward and simple, if it >> only was modeled with objects. >> >> Hey, that's what Smalltalk is made for and what it still claims to be >> its USP. Store is a proprietary solution anyway and its SQL tables >> are of no use for any other application, so moving it to Smalltalk >> objects will not loose any functionality or buzz word feature. IMO >> the contrary is true: A Smalltalk Store implemented entirely in >> Smalltalk would further add to its credibility. >> >> I would expect the Store subsystem to shrink vastly in complexity. >> Concerning persistence, an object-based implementation would probably >> also be more easily integrateable with industry standard file-based >> versioning systems, which would even add another buzz word. >> >> Andre >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > -- > Alan Knight [|], Engineering Manager, Cincom Smalltalk [hidden email] > [hidden email] http://www.cincom.com/smalltalk > > > > This message may contain confidential information and is intended for > specific recipients unless explicitly noted otherwise. If you have > reason to believe you are not an intended recipient of this message, > please delete it and notify the sender. This message may not represent > the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries > or affiliates, and does not constitute a contract or guarantee. > Unencrypted electronic mail is not secure and the recipient of this > message is expected to provide safeguards from viruses and pursue > alternate means of communication where privacy or a binding message is > desired. > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by James Robertson-7
A client/server is the way to go. The appropriate protocol
and services could signficantly speed up operations as well as provide a platform for additional team features. However, as James indirectly pointed out that it also needs to address the single developer who wants a simple repository. This would imply that the server should also be capable of running in a development image in a seamless manner so the developer could simply load the appropriate store package and be up and running, like you can now. Additional complexity would then be felt as a team scales up, but usually at this point the gains would justify the additional effort required to support the client/server split. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of James Robertson > Sent: Wednesday, February 11, 2009 10:37 AM > To: VW NC > Subject: Re: [vwnc] Store performance strategies > > To play devil's advocate for a moment, bear in mind that a client/ > server Store would up the complexity level of using Store by a fair > bit. Right now, if you use Postgres, the whole thing is fairly simple > > If you create a client/server setup, you start running into various > issues - > > -- do I need a separate machine for the server? > -- do I have firewall related issues with the server? > -- Can I even version code w/o a server? > > > James Robertson > Cincom Smalltalk Product Evangelist > http://www.cincomsmalltalk.com/blog/blogView > Talk Small and Carry a Big Class Library > > > > > On Feb 11, 2009, at 10:19 AM, Paul Baumann wrote: > > > Alan, > > > > That would be fun, but I prioritize work by reward. That work is the > > domain of a Cincom project. If Cincom had a vast customer base to > > market to--then perhaps it would get on my list of things to do. > > Failing a market, improvements like these should the interest of a > > Cincom development manager...or not, depending on the future desired > > or legacy safeguarded. Store is very good but it is slower than it > > could be--a point that you acknowledge. > > > > Regards, > > > > Paul Baumann > > > > -----Original Message----- > > From: Alan Knight [mailto:[hidden email]] > > Sent: Wednesday, February 11, 2009 9:32 AM > > To: Andre Schnoor; Paul Baumann > > Cc: VWNC > > Subject: Re: [vwnc] Store performance strategies > > Importance: High > > > > Interesting, I never received Paul's response that's excerpted here, > > and it doesn't appear to be my local spam filter that did it. > > However, he's certainly welcome to do what's described here instead > > of setting up a replicator :-) > > > > At 04:18 AM 2/11/2009, Andre Schnoor wrote: > > > >> On 10.02.2009, at 18:39, Paul Baumann wrote: > >> > >>> A completely different strategy is to adapt Store by adding a server > >>> interface for higher-level operations. > >> > >> +1 > >> > >> Not only for higher-level operations. I would like to see the entire > >> Store implementation separated from the development images (OpenTalk > >> STST). Clients should be tiny. Considering todays computing > >> resources, > >> SQL/RDB is an anachronism. Even more so as the task of maintaining > >> source code is rather straightforward and simple, if it only was > >> modeled with objects. > >> > >> Hey, that's what Smalltalk is made for and what it still claims to be > >> its USP. Store is a proprietary solution anyway and its SQL tables > >> are > >> of no use for any other application, so moving it to Smalltalk > >> objects > >> will not loose any functionality or buzz word feature. IMO the > >> contrary > >> is true: A Smalltalk Store implemented entirely in Smalltalk would > >> further add to its credibility. > >> > >> I would expect the Store subsystem to shrink vastly in complexity. > >> Concerning persistence, an object-based implementation would probably > >> also be more easily integrateable with industry standard file-based > >> versioning systems, which would even add another buzz word. > >> > >> Andre > >> > >> _______________________________________________ > >> vwnc mailing list > >> [hidden email] > >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > -- > > Alan Knight [|], Engineering Manager, Cincom Smalltalk > > [hidden email] [hidden email] http://www.cincom.com/smalltalk > > > > > > > > This message may contain confidential information and is intended > > for specific recipients unless explicitly noted otherwise. If you > > have reason to believe you are not an intended recipient of this > > message, please delete it and notify the sender. This message may > > not represent the opinion of IntercontinentalExchange, Inc. (ICE), > > its subsidiaries or affiliates, and does not constitute a contract > > or guarantee. Unencrypted electronic mail is not secure and the > > recipient of this message is expected to provide safeguards from > > viruses and pursue alternate means of communication where privacy or > > a binding message is desired. > > > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by Paul Baumann
I'm not making any performance claims of any kind, actually. Just
noting that a client/server setup is going to be more complex. James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On Feb 11, 2009, at 11:05 AM, Paul Baumann wrote: > -- do I need a separate machine for the server? > > A separate machine would defeat the purpose of avoiding > communication latency. > > -- do I have firewall related issues with the server? > > Yes, a port would need to be opened. Part of the cost of having the > faster server. > > -- Can I even version code w/o a server? > > The server can be thought of as a VW image that runs on the same box > as the dB and that is available to handle higher-level operations if > requested. It would be an optional interface. It would sit on-top-of > the exsting store framework. If the server is not running or is too > busy then code should fall through to the standard techniques. > > Are you saying that replacing Oracle with Postgres is all that needs > to be done to improve Store performance? I'm not seeing how > replacing one RDBMS with another does it--unless you are also > talking about special object features of Postgres that would (or > could?) be used. That would be great if the solution was so simple. > > Paul Baumann > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of James Robertson > Sent: Wednesday, February 11, 2009 10:37 AM > To: VW NC > Subject: Re: [vwnc] Store performance strategies > > To play devil's advocate for a moment, bear in mind that a client/ > server Store would up the complexity level of using Store by a fair > bit. Right now, if you use Postgres, the whole thing is fairly simple > > If you create a client/server setup, you start running into various > issues - > > -- do I need a separate machine for the server? > -- do I have firewall related issues with the server? > -- Can I even version code w/o a server? > > > James Robertson > Cincom Smalltalk Product Evangelist > http://www.cincomsmalltalk.com/blog/blogView > Talk Small and Carry a Big Class Library > > > > > On Feb 11, 2009, at 10:19 AM, Paul Baumann wrote: > >> Alan, >> >> That would be fun, but I prioritize work by reward. That work is the >> domain of a Cincom project. If Cincom had a vast customer base to >> market to--then perhaps it would get on my list of things to do. >> Failing a market, improvements like these should the interest of a >> Cincom development manager...or not, depending on the future desired >> or legacy safeguarded. Store is very good but it is slower than it >> could be--a point that you acknowledge. >> >> Regards, >> >> Paul Baumann >> >> -----Original Message----- >> From: Alan Knight [mailto:[hidden email]] >> Sent: Wednesday, February 11, 2009 9:32 AM >> To: Andre Schnoor; Paul Baumann >> Cc: VWNC >> Subject: Re: [vwnc] Store performance strategies >> Importance: High >> >> Interesting, I never received Paul's response that's excerpted here, >> and it doesn't appear to be my local spam filter that did it. >> However, he's certainly welcome to do what's described here instead >> of >> setting up a replicator :-) >> >> At 04:18 AM 2/11/2009, Andre Schnoor wrote: >> >>> On 10.02.2009, at 18:39, Paul Baumann wrote: >>> >>>> A completely different strategy is to adapt Store by adding a >>>> server >>>> interface for higher-level operations. >>> >>> +1 >>> >>> Not only for higher-level operations. I would like to see the entire >>> Store implementation separated from the development images (OpenTalk >>> STST). Clients should be tiny. Considering todays computing >>> resources, SQL/RDB is an anachronism. Even more so as the task of >>> maintaining source code is rather straightforward and simple, if it >>> only was modeled with objects. >>> >>> Hey, that's what Smalltalk is made for and what it still claims to >>> be >>> its USP. Store is a proprietary solution anyway and its SQL tables >>> are of no use for any other application, so moving it to Smalltalk >>> objects will not loose any functionality or buzz word feature. IMO >>> the contrary is true: A Smalltalk Store implemented entirely in >>> Smalltalk would further add to its credibility. >>> >>> I would expect the Store subsystem to shrink vastly in complexity. >>> Concerning persistence, an object-based implementation would >>> probably >>> also be more easily integrateable with industry standard file-based >>> versioning systems, which would even add another buzz word. >>> >>> Andre >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> -- >> Alan Knight [|], Engineering Manager, Cincom Smalltalk [hidden email] >> [hidden email] http://www.cincom.com/smalltalk >> >> >> >> This message may contain confidential information and is intended for >> specific recipients unless explicitly noted otherwise. If you have >> reason to believe you are not an intended recipient of this message, >> please delete it and notify the sender. This message may not >> represent >> the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries >> or affiliates, and does not constitute a contract or guarantee. >> Unencrypted electronic mail is not secure and the recipient of this >> message is expected to provide safeguards from viruses and pursue >> alternate means of communication where privacy or a binding message >> is >> desired. >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > This message may contain confidential information and is intended > for specific recipients unless explicitly noted otherwise. If you > have reason to believe you are not an intended recipient of this > message, please delete it and notify the sender. This message may > not represent the opinion of IntercontinentalExchange, Inc. (ICE), > its subsidiaries or affiliates, and does not constitute a contract > or guarantee. Unencrypted electronic mail is not secure and the > recipient of this message is expected to provide safeguards from > viruses and pursue alternate means of communication where privacy or > a binding message is desired. > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by Andre Schnoor
Andre Schnoor escreveu:
> On 10.02.2009, at 18:39, Paul Baumann wrote: > >> A completely different strategy is to adapt Store by adding a server >> interface for higher-level operations. > > +1 > +1 > Not only for higher-level operations. I would like to see the entire > Store implementation separated from the development images (OpenTalk > STST). Clients should be tiny. Considering todays computing resources, > SQL/RDB is an anachronism. Even more so as the task of maintaining > source code is rather straightforward and simple, if it only was > modeled with objects. > > Hey, that's what Smalltalk is made for and what it still claims to be > its USP. Store is a proprietary solution anyway and its SQL tables are > of no use for any other application, so moving it to Smalltalk objects > will not loose any functionality or buzz word feature. IMO the > contrary is true: A Smalltalk Store implemented entirely in Smalltalk > would further add to its credibility. Agreed and seconded. > > I would expect the Store subsystem to shrink vastly in complexity. > Concerning persistence, an object-based implementation would probably > also be more easily integrateable with industry standard file-based > versioning systems, which would even add another buzz word. Which IMNSO should be the driving motive to update it. -- Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/ _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by James Robertson-7
James Robertson escreveu:
> To play devil's advocate for a moment, bear in mind that a client/ > server Store would up the complexity level of using Store by a fair > bit. Right now, if you use Postgres, the whole thing is fairly simple > > If you create a client/server setup, you start running into various > issues - > > -- do I need a separate machine for the server? Not necessarily. A server could a process running in the same machine (as it's done with CVS, for example). > -- do I have firewall related issues with the server? The same as all other applications that use TCP/IP (even for communication within the same machine). > -- Can I even version code w/o a server? With the proviso I made above, _yes_ :-) -- Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/ _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by James Robertson-7
> If you create a client/server setup, you start running into various > issues - > > -- do I need a separate machine for the server? > -- do I have firewall related issues with the server? > -- Can I even version code w/o a server? Absolutely agree. However, you have these questions and concerns with a database server too. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by Paul Baumann
> A separate machine would defeat the purpose of avoiding > communication latency. This is a myth. Our customers are streaming live midi and audio over IP, doing sort of load balancing in a music production studio where latency is a critical factor. In a modern LAN, latencies are virtually non-exsitent. At least latency is nothing one could perceive in client/server connections (provided the socket connections are kept open). Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by Terry Raymond
Am 11.02.2009 um 17:12 schrieb Terry Raymond: > However, as James indirectly pointed out that it also needs > to address the single developer who wants a simple repository. IMO, running a separate process on the same machine is trivial and not even worth mentioning nowadays. The benefits clearly outweigh the costs (if there are any at all). I consider a SQL database server more complicated to setup and maintain than another VW image. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by James Robertson-7
Am 11.02.2009 um 17:22 schrieb James Robertson: > I'm not making any performance claims of any kind, actually. Just > noting that a client/server setup is going to be more complex. It's just objects and messages. Opentalk STST would be a wonderful foundation for this. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
In reply to this post by Paul Baumann
Hi Paul;
Based on customer feedback, we set out to make improvements in 3 areas of Store - Speed - Merge capability - Configuration management Store improvements slated for VW7.7 include: - Extensive use of Glorp which should provide some improvements in reducing chattiness and improving performance - Merge tool improvements - Atomic loading capability The first item is fairly extensive, and gives us a much better foundation to make more improvements, performance and otherwise. Alan's suggestion about replication is an available solution that we've seen successful results for. I appreciate everyone's ideas of alternative solutions for Smalltalk code management. Right now, providing some serious resource and attention to some Store issues was the most expeditious way to help the most customers solve their problems. Thanks Arden On Feb 10, 2009, at 12:39 PM, Paul Baumann wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Store performance strategies
|
|
Thanks Arden,
Store performance improvements would be appreciated. I look forward to VW 7.7.
ICE has created tools for merging and publishing code. They are in the Public Repository as part of "GemKit GemStone Source Code Management". The most notable
feature of the Release Assistant tool is that it allows for limited path merges. Basically it allows you to merge a recent set of changes from a forked code path without seeing all the earlier changes that are not relevant to that merge. That one feature is
a huge time saver in itself, but that is just one feature of a tool that would be difficult to do without. Hopefully you are doing something like that.
I presume configuration management changes would be the ability to modify bundle specifications or package prerequisites that are not loaded. That comes
in handy at times.
Paul Baumann
From: Arden Thomas [mailto:[hidden email]] Sent: Wednesday, February 11, 2009 4:50 PM To: Paul Baumann Cc: VWNC Subject: Re: [vwnc] Store performance strategies Importance: High Based on customer feedback, we set out to make improvements in 3 areas of Store
- Speed
- Merge capability
- Configuration management
Store improvements slated for VW7.7 include:
- Extensive use of Glorp which should provide some improvements in reducing chattiness and improving performance
- Merge tool improvements
- Atomic loading capability
The first item is fairly extensive, and gives us a much better foundation to make more improvements, performance and otherwise.
Alan's suggestion about replication is an available solution that we've seen successful results for.
I appreciate everyone's ideas of alternative solutions for Smalltalk code management.
Right now, providing some serious resource and attention to some Store issues was the most expeditious way to help the most customers solve their problems.
Thanks
Arden
On Feb 10, 2009, at 12:39 PM, Paul Baumann wrote:
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |