Re: Java databases as alternative to MySQL on OS X Server? (OT)
Mieke Banderas wrote: Mike Sabroff suggested: Cloudscape is it faster than Apache Derby in your experience? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The IBM Cloudscape database engine is the Apache Derby database engine so performance is identical between given versions of each. For more information on Cloudscape and Derby see the section: About the names Derby and Cloudscape in the document: Cloudscape Version 10: A technical overview at: http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408anderson/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
Mike Sabroff suggested: Cloudscape is it faster than Apache Derby in your experience? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
On Tuesday, 29 בNovember 2005 03:21, Mieke Banderas wrote: Oded Arbel said: b) Even assuming they are right, you still want to choose MySQL over JVM space databases, because Java and Java databases are very much thread enabled and create and destroy many threads. But do they do it mainly within the OS or within the JVM? The JVM can't create threads without OS support. Even user-space threads need some OS support. Top or PS doesn't show individual processes within the JVM. That means they use kernel threads. I'm not clear on how Java processes/threads relate to OS processes/threads. to know where/how exactly Java threads are started/killed on Hotspot in OS X. Doesn't java threads mainly intercommunicate within the JVM? Context switches? Not an OS X expert, but from Anandtech explanations and from what I've read elsewhere, Java threads are kernelthreads and are mapped to Mach threads. inter-thread communication in java is done through shared memory - shared variables, but the Java memory sharing model doesn't really share memory, Instead it uses thread local storage to store copies of shared variables and when you cross into or out of a synchronized block, the contents of the variables are copied. That means a lot of context switches through the kernel, and if you OS doesn't do that very well (and few do it as well as Solaris), then you'd be hard pressed for performance. Is it really a completely dead end that minimizing the OS threading in Mac OS X and keeping threads within JVM could improve performance? As discussed above, there isn't much difference. Of course the Java DB in question would have to be somewhat similar to MySQL in performance, but possibly the Java DB could perform better with many connections as that is where MySQL on OS X breaks down according to anandtech. I believe you wont see much improvement, if at all. MySQL OTOH uses very little threads - essentially it only creates a new thread to handle a new client, and even then a single thread handles several clients before another thread is required. But according to the anandtech article OS X is the only platform where performance breaks down after raising the amount of connections. So it would seem until Apple fixes the performance problems - which certainly may take a while-, ways to use databases without creating many expensive (in theory) OS threads could be desirable. That is if you subscribe to Anandtech's explanation that the poor MySQL performance is the result of poor threading performance. I think I provided enough evidence that their conclusions will not be taken at face value. Again, not an OS X expert, but I think its much more likely that the MySQL have problems with locking and context switches, as Anandtech themselves have mentioned and even quoted MySQL on the issue - and immediately disregarded it in favor of the thread theory. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. Conscience is what hurts when everything else feels so good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
On Tuesday, 29 בNovember 2005 05:12, Mieke Banderas wrote: I wonder how much faster Linux could run on my G3 server hardware. I would have lots of work replacing all the built in services in Mac OS X Server to give me all that control also in Linux, buy maybe I have to. I'm a bit cashstrapped for new hardware, so I need to get as much performance I can. Or perhaps I should try to get a PC just for the DBs. As Anandtech's tests suggest, a good PC or even Linux on Apple hardware will give you much better performance. This is probably due to the better locking that Linux implements (read about futex() ). That being said, I suspect that Linux on a G3 will give you less performance then you can get today with a midrange PC that would cost you less then US$ 1000 (probably less then half of that if you don't need it rack mounted). BTW - I think that their tests aren't much fair in the hardware department. They compare an end of the line architecture (G5) which hasn't had any serious improvement done for it in the last two years, with the latest and greatest of the two top performers of the micro-computer world, whose chips (same chips that were tested) are powering the worlds fastest super computers. Its a credit to Apple and the G5 line that they only lost by about 10%. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. If you sell diamonds, you cannot expect to have many customers. But a diamond is a diamond even if there are no customers. -- Swami Prabhupada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java databases as alternative to MySQL on OS X Server? (OT)
From: Oded Arbel [mailto:[EMAIL PROTECTED] Subject: Re: Java databases as alternative to MySQL on OS X Server? (OT) inter-thread communication in java is done through shared memory - shared variables, but the Java memory sharing model doesn't really share memory, Instead it uses thread local storage to store copies of shared variables and when you cross into or out of a synchronized block, the contents of the variables are copied. That's one of the most bizarre and blatantly wrong descriptions of the Java memory model that I've ever read. All Java objects reside in the Java heap, which is shared across all threads of the JVM process and directly referenceable by all. Local variables for a Java method exist in each thread's Java stack, which is normally not shared across threads other than for garbage collection operations. Entering a synchronized block in a HotSpot-based JVM normally does not require any context switching, since the lock on an object is established via the platform's compare-and-exchange instruction; only if a conflict exists are kernel services required to suspend the conflicting thread. (This is also true of the JRockit and IBM JVMs, as well as several others.) No copying of local variable is ever performed; on some OS implementations, parameters are copied when calling a kernel service that requires a context switch but that occurs within the OS, not the JVM. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
On Tuesday, 29 בNovember 2005 17:28, Caldarale, Charles R wrote: From: Oded Arbel [mailto:[EMAIL PROTECTED] Subject: Re: Java databases as alternative to MySQL on OS X Server? (OT) inter-thread communication in java is done through shared memory - shared variables, but the Java memory sharing model doesn't really share memory, Instead it uses thread local storage to store copies of shared variables and when you cross into or out of a synchronized block, the contents of the variables are copied. That's one of the most bizarre and blatantly wrong descriptions of the Java memory model that I've ever read. Rather simplified and not accurate where accuracy would have caused me to get way off topic, but all in all not really incorrect. All Java objects reside in the Java heap, which is shared across all threads of the JVM process and directly referenceable by all. Please read up on your Java memory model. What you describe is a nice abstraction that many Java developers have in their mind, but is technically not correct and can't be correct when you consider multiple processors, DMA, hyper-threading or even just plain old L2 CPU caches. [http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html] [http://www.developer.com/java/article.php/951051] [http://www-128.ibm.com/developerworks/library/j-jtp02244.html] Also please note that JSR-133, once implemented, supposedly makes the whole discussion irrelevant as it forces read/write ordering. But AFAIK, only Sun's JVM 5.0 (1.5) implements it and I'm not sure about its correctness. Entering a synchronized block in a HotSpot-based JVM normally does not require any context switching, since the lock on an object is established via the platform's compare-and-exchange instruction; only if a conflict exists are kernel services required to suspend the conflicting thread. You are obviously disregarding the fact that Java is a multi-platform environment, and some platforms (notably the Mac OS-X which started the whole thread) does not provide such a mechanism. Are you an MS-Windows programmer by any chance ? No copying of local variable is ever performed; If it ever appeared that I was talking about 'local variables' when I wrote the word 'local' then I'm deeply sorry, and I here-by request that you please re-read my original post more carefully. The word local in this case was used to denote the running thread's view on the shared variables, also knows as thread local storage (do look up that concept as well when you read about the Java memory mode, please). -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. When the student is ready the master appears. -- Japanese proverb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java databases as alternative to MySQL on OS X Server? (OT)
From: Oded Arbel [mailto:[EMAIL PROTECTED] Subject: Re: Java databases as alternative to MySQL on OS X Server? (OT) Please read up on your Java memory model. What you describe is a nice abstraction that many Java developers have in their mind, but is technically not correct and can't be correct when you consider multiple processors, DMA, hyper-threading or even just plain old L2 CPU caches. You have to be careful about what viewpoint you're using. From a Java programmer's perspective, as well as actual JVM implementation, what I said is true (although I left out any discussion of volatility and visibility of writes in a multi-CPU system). From a hardware or JIT implementer perspective, what you said is appropriate, since it applies primarily to CPU pipelines and other low-level memory writers (not threads per se), but isn't terribly relevant from a practical Java programming perspective. Essentially all high-performance systems have operated with some variation of these considerations from day one, due to the potential of asynchronous I/O modifying the instruction stream. The introduction of write buffers into CPU pipelines twenty-odd years ago really exacerbated the situation. Also please note that JSR-133, once implemented, supposedly makes the whole discussion irrelevant as it forces read/write ordering. Only for intra-thread actions; for inter-thread, ordering is specified primarily with regards to entities marked volatile and synchronized operations. But AFAIK, only Sun's JVM 5.0 (1.5) implements it and I'm not sure about its correctness. Actually, JSR 133 largely reflects what the 1.4 HotSpot JVM had already implemented. As you say, the jury is still out on whether all of the low-level synch points have been covered. You are obviously disregarding the fact that Java is a multi-platform environment, and some platforms (notably the Mac OS-X which started the whole thread) does not provide such a mechanism. The PowerPC instruction set includes lwarx and stwcx for this purpose. If the JIT in the OS X JVM does not generate code to use these for object synchronization, it would be seriously deficient compared to all other commercial JVMs. Without generating such code inline, any multi-threaded interactions are bound to be horribly slow. Are you an MS-Windows programmer by any chance ? Only when I can't avoid it. Started working on multi-CPU systems in 1969, so I'm quite familiar with synchronization and data visibility concerns. 35+ years of doing software and hardware design on a variety of platforms, including several patents for various features of our systems. Currently responsible for (among other things) the JVM implementation on our 36-bit ones-complement mainframes (and yes, our JVM does pass all the compatibility tests). So much for disregarding multi-platform issues. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
On Monday, 28 בNovember 2005 19:59, Mieke Banderas wrote: are there any javabased DB alternatives, that may perform better than MySQL (or PostgreSQL for that matter)? I prefer free, open sourced DBs or otherwise with a license that could fit a small business/non profit organisation. HSQLdb (formerly known as Hypersonic SQL) and Apache Derbi (formerly knows as cloudscape DB) are two Pure Java databases, which are free and open source, and at least the first can run in memory in the JVM. As for faster performing ? I think you'd be hard pressed to find something better performing then MySQL and Postgres. Might want to try firebird, though I wouldn't get your hopes up. I don't enough of JVMs to know if Javabased DBs are usually better performancewise than MySQL/PostgreSQL, I can't really see how it could be, and my experience indeed shows the opposite. but my thought was that if everything is kept within the JVM, the weak performance spots in OS X would be minimized as threads would be handled within JVM rather than within OS X. Threads being being the prime suspect in the weak MySQL performance in OS X according Anandtech. I'm not sure why do they think that, and I haven't read the entire article yet, but I doubt you'd get better performance from an internal DB then from a standalone highly optimized full RDBMs. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. The marvels of today's modern technology include the development of a soda can, when discarded will last forever ... and a $7,000 car which when properly cared for will rust out in two or three years. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
On Monday, 28 בNovember 2005 19:59, Mieke Banderas wrote: Given the sad, sad performance findings at: No More Apple Mysteries, Part Two Date: September 1st, 2005 http://www.anandtech.com/mac/showdoc.aspx?i=2520 I don't enough of JVMs to know if Javabased DBs are usually better performancewise than MySQL/PostgreSQL, but my thought was that if everything is kept within the JVM, the weak performance spots in OS X would be minimized as threads would be handled within JVM rather than within OS X. Threads being being the prime suspect in the weak MySQL performance in OS X according Anandtech. After reading the article I can say two things: a) I think their take on the thread vs. process creation issue is completely wrong. They are basically saying thread creation on linux is the same as process creation and is very fast, but thread creation on MAC OSX is not the same as process creation because process creation also creates a task. Because we tested process creation to be slower on MAC OSX, we conclude that thread creation is slower. Am I the only one that see how broken the logic here ? b) Even assuming they are right, you still want to choose MySQL over JVM space databases, because Java and Java databases are very much thread enabled and create and destroy many threads. MySQL OTOH uses very little threads - essentially it only creates a new thread to handle a new client, and even then a single thread handles several clients before another thread is required. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. General Failure's Fault. Not Yours. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
Oded Arbel said: b) Even assuming they are right, you still want to choose MySQL over JVM space databases, because Java and Java databases are very much thread enabled and create and destroy many threads. But do they do it mainly within the OS or within the JVM? Top or PS doesn't show individual processes within the JVM. I'm not clear on how Java processes/threads relate to OS processes/threads. I'd like to know where/how exactly Java threads are started/killed on Hotspot in OS X. Doesn't java threads mainly intercommunicate within the JVM? Context switches? Is it really a completely dead end that minimizing the OS threading in Mac OS X and keeping threads within JVM could improve performance? Of course the Java DB in question would have to be somewhat similar to MySQL in performance, but possibly the Java DB could perform better with many connections as that is where MySQL on OS X breaks down according to anandtech. MySQL OTOH uses very little threads - essentially it only creates a new thread to handle a new client, and even then a single thread handles several clients before another thread is required. But according to the anandtech article OS X is the only platform where performance breaks down after raising the amount of connections. So it would seem until Apple fixes the performance problems - which certainly may take a while-, ways to use databases without creating many expensive (in theory) OS threads could be desirable. Obviously the only way to know for sure if this is true would be to test load MySQL on ones own server and also test load a Java database. Do anyone know of anyone who have done load testing on OS X and published the results? I'm on OS X Server 10.2 so even older tests are of interest. (I'm going to google it now of course) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
Mieke Banderas said: I'd like to know where/how exactly Java threads are started/killed on Hotspot in OS X. Doesn't java threads mainly intercommunicate within the JVM? Context switches? Is it really a completely dead end that minimizing the OS threading in Mac OS X and keeping threads within JVM could improve performance? It would seem so, as I now learnt that The HotSpot JVM uses native threads. The only possible escape then would be to use another JVM that doesn't on OS X. But I'm not sure how advisable that is. Anyone uses alternative JVMs on OS X out there? I downloaded AppPerfect Test Studio http://www.appperfect.com/ products/devsuite/jp.html to see if I can build a test case and test my current server and perhaps make comparisons with some of the suggested Java DBs later. AppPerfect support was very helpful suggesting test methods. Anyone out there testing their webapplications with this product? I wonder how much faster Linux could run on my G3 server hardware. I would have lots of work replacing all the built in services in Mac OS X Server to give me all that control also in Linux, buy maybe I have to. I'm a bit cashstrapped for new hardware, so I need to get as much performance I can. Or perhaps I should try to get a PC just for the DBs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Java databases as alternative to MySQL on OS X Server? (OT)
From: Mieke Banderas [mailto:[EMAIL PROTECTED] Subject: Re: Java databases as alternative to MySQL on OS X Server? (OT) It would seem so, as I now learnt that The HotSpot JVM uses native threads. The only possible escape then would be to use another JVM that doesn't on OS X. But I'm not sure how advisable that is. Anyone uses alternative JVMs on OS X out there? The last JVM I know of that avoided native threads was Sun's 1.3 version running in green threads mode. Performance and stability were nothing to brag about. There are several academic JVMs kicking around with varying degrees of stability and compliance with the spec that might not use native threads. None are really appropriate for production use. I've only toyed with it, but Solaris 10, along with Postgres, is available for free download, ready to install and run on an x64/x86 system. Yet another learning curve... - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
