Hi Richard, I like your clarification about "the only reason for having multiple threads... is to share state..."
And, yes, the state that I'm sharing is persistent within an object database — so I can deploy multiples of the same image, each accessing the database. This is the scenario (c) in my 2nd post utilizing a load distributor setup. This is certainly a proven and viable way to add capacity to handle increased web user traffic. But, it is still problematic for my use-case and business-case. Allow me to explain.
In the late 1990's and early 2000's, I ran my own server room at great expense. To save costs, eventually migrated to a co-location facility where I installed my servers in a rack and paid the monthly fees. Today, I'm able to utilize Virtual Private Servers (or "VPSs") available from DigitalOcean, Vultr, Amazon and others. In each of the server hosting scenarios, costs tend to be proportionate to the number of CPUs, amount of RAM and Disk Space.
We have been providing an ecommerce hosting service for wholesalers, distributors and manufacturers. Also, we have some retail web store customers. As my system design and architecture is ideally capable of supporting fast growing enterprises and multi-tenant configurations, the business-case is sensitive to costs for CPU, RAM and disk space.
The multi-Smalltalk-image configuration with distribution of web traffic does work, but is too costly in terms of RAM use. Each VAST image is 47 MB on disk but can exceed 100 MB in terms of RAM memory utilization. Launching additional images ramps up RAM requirements and associated costs. Therefore, my desire for an image/VM that can utilize multiple CPUs and be more efficient in terms of RAM (and setup times for a distributed image scenario).
In the early days, pre year 2000, we looked at several database options including Gemstone, Versant, Objectivity, Omnibase, Object-Relational frameworks and others. At that time, 32 bit CPUs limited the amount of RAM we could put into a server box and RAM was very costly. Gemstone was high on our list but utilized too much RAM for our scaling needs versus memory costs. We decided on a database and configuration that would maximize our memory resources, saving costs as our customer base grew.
Today, we are still sensitive to the cost of server RAM. Therefore, the ideal scenario is to have one image that is multi-CPU capable to enable scaling web traffic without being forced to launch multiple images. At this point, we find C# on .NET to be the most CPU and RAM efficient for web app deployment. I would much rather have a Smalltalk centric solution.
I've learned from each of the posts in this topic/thread. I'm grateful for the insights and feedback. Still, I believe a multi-CPU capable Smalltalk would be highly desirable for my own purposes and also to underpin large WordPress scale projects that might showcase Smalltalk on a bigger stage. In my opinion, lack of such multi-CPU capabilities removes Smalltalk from consideration for Facebook scale projects or those projects that plan to grow/scale quickly.
My perception is that VAST has many Fortune 2000 customers with defined workloads that are not as sensitive to server costs. But, for Internet startups and small businesses that hope to grow quickly, the software systems must be able to scale cost efficiently. It would be great to have Smalltalk's developer productivity AND .NET's scalability. Maybe someone will see the promise of Essence#, a Smalltalk on top of .NET, as a foundation for a great Smalltalk of the future.
https://essencesharp.wordpress.com/