Is there any reason in particular why it's recommended to run memcached on a Linux server? Is it really that bad an idea to run it on a Windows Server box? What about an OS X Server box?
The biggest reason that I read is about TCO. In other words, for each windows box that we run memcached on, we have to buy a copy of Windows Server and those costs add up. The thing is that we have several servers that have older processors but a lot of RAM - perfect for memcached use. All of these boxes already have Windows Server 2003 installed on them, so there's not really much savings to installing Linux. Are there any other compelling reasons to use Linux?
This question is really "what are the advantages of Linux as a server platform" I'll give a few of the standard answers:
Easier to administer remotely (no need for RDP, etc.) Everything can be scripted or done via CLI.
Distributions like the Ubuntu LTS (Long Term Support) versions guarantee security updates for years with zero software cost. Updates can easily be installed via command line, and generally don't require a reboot.
Higher performance. Linux is generally considered to offer "more bang for the buck" on a given piece of hardware. This is generally due to lower resource requirements.
Lower resource requirements. Linux runs just great on 256MB or less of RAM, and on very small CPUs
Breadth of available software & utilities.
It's free. (As in beer)
It's free. (As in freedom) This means you can see, change, and file bugs against the code you're running, and talk directly with the developers.
Remember, that TCO includes the amount of time that you (the administrator) are spending to maintain the machine. Linux has a lower TCO because it's easier to maintain, and you can spend your time doing something other than administering a server...
Almost all of the FAQs and HOWTOs are written from Linux point of view. Memcache was originally created only for Linux, the ports came later. There is port to Windows, but it's not yet in the official memcache distribution. Memcache on Windows is still guerrilla style. For example there is no memcache for x64 Windows.
As of memcache on MacOS X on servers: niche of niche of niche.
There doesn't seem to be any technical disadvantage to running it in windows. It's mainly a cost thing. If the licenses are just sitting around unused, there's probably no disadvantage at all. I do recall problems on older windows with memory leaks in older windows APIs, particularly the TCP stuff -- but presumably that stuff is all fixed in modern windows.
If you are deploying memcached you probably have a fairly significant infrastructure (many, many machines already deployed). Even if you are dedicating new machines to memcached, you'll want to run some other software on them for system management, monitoring, hardware support etc. This software may be customised by your team for your infrastructure.
Therefore, your OS platform choice will be guided by what your operations team and hardware vendor will support for use in production.
The cost of a few Windows licences is probably fairly immaterial and you probably have a bulk subscription already - in fact the servers may be ordered with Windows licences already on them.
Having said that, you will definitely want a 64-bit OS if you're running memcached - using a 32-bit OS is not clever and will mean that most of your RAM cannot be used (you'll be limited to around 3G depending on the OS).
I'm assuming that if you're deploying memcached, you'll be doing so on hardware with LOTS of ram - it's pretty pointless otherwise, after all.
Related
Now to test the websites I use multiple virtual machines (VirtualBox) with Web browsers.
I want to make portable versions of browsers (to collect IE, Opera, Safari, FF, Chrome and maybe another). I want that browser have development tool (e.g. like Firebug).
For virtualization apps I found several solutions:
BoxedApp
Cameyo
JauntePE
Spoon Studio / Xenocode Virtual Application Studio
VMware ThinApp
MoleBox Virtualization Solution
Tell me what there are and what should I choose for my task?
As far as I know, if to use boxedapp, your an application will run properly even if it doesn't have the right to write to the system registry.
I personally use VMWare Workstation. It has never given me problems. I'd recommend it.
In terms of what there is available out there, there is a ridiculous amount of programs to choose from.
There are my two cents! Hope this helps and good luck!
Can you please clarify what you are asking?
The assumption made by Jebego, and my understanding of your question, is that you are interesting in finding out what different Virtualization tools are available, though your comment:
I want to assemble a collection of browsers for testing as portable application. In addition to its main functions I want to be able to see html \ css \ js or something like Firebug.
Is slightly misleading as it refers to browsers.
Other useful information you may want to include is the size of your budget. You mention that you are currently using VirtualBox, which is Open Source, so I am assuming you ideally are looking for products which are free.
Anyway assuming my assumptions are correct, I can give details on a couple of options which I have experience with:
Micsoroft Virtual PC - I found Microsoft Virtual PC easy to set up and get started with. It is a free download, and if you have Windows 7 installed then I believe it is built into the OS. If you're looking for seomthing fairly basic, simply to run your application in a browser for testing purposes then this may be sufficient. Virtual PC allows you to allocate a specfic amount of RAM to each VM, but you cannot go over 3,712MB, which is pretty limiting if you need to do anything requiring significant resources inside the VM.
VMWare Server - I recently moved to VMWare Server 2.0, also a free product. I use a virtual machine for development tasks, and found that the RAM limit on Virtual PC was too low to run the developer tools and add-ins at a suitable speed. With VMWare Server, you can allocate as much RAM as you see fit (obviously you need to have it available in the host machine), and you can also specify the number of CPUs to allocate to the VM. The setup is slightly less starightforward than Virtual PC, but by no means complicated. The tools provided by VMWare offer more configuration options (such as those mentioned above).
This is a brief summary of my experience, I'd be happy to give more detail on either if you so require.
Some general things to bear in mind when choosing virtualisation software:
What OS do you plan to install on the guest? Some Virtualisation software is better suited to specific OS'es
How much poower do you need inside your guest VM? Again, this will influence your decision on which way to go.
Hope this helped, good luck with your search.
I'm currently providing 32 bit Windows music software. Some of my users are asking for 64-bit support. I plan to eventually, but porting is a big job, and I have plenty of other important feature requests too. I need to allocate my limited time wisely.
How much market share do 64-bit operating systems hold?, and what's the trend.
No better time than now. As the need for more ram increases 64 bit windows versions will get more and more prevalent. Play around a bit with Google trends and you will see a clear uptick in people looking into it. As explained in "Dude, Where's My 4 Gigabytes of RAM?" the need for the every day user to go to a 64bit OS is just going to keep growing.
Edit in response to Jeff's comment
I understand, any team will have to balance upgrades/bug fixes by priority. That will always be a difficult balance to strike. The benefits of a 64 bit version will only continue to grow!
Good luck striking the right balance!
Why are they asking for 64-bit support? Does your 32-bit software not work on Win64, or are they assuming they need a special version when in fact they'd be fine with the 32-bit version? In my experience, Win64's support for 32-bit programs is excellent, and it's likely to continue to exist for the foreseeable future.
If your software doesn't work, and it's not due to a fundamental limitation like half the logic being in a device driver, then making it work as 32-bit executable may be easier than you think.
(Forgive me if I'm teaching you to suck eggs. 8-)
There are 3 common things that would be good reasons to port to Win64:
your product includes a driver - in this case to work at all on a Win64 system, at least the driver must be ported.
your product has shell or IE integration - since on a Win64 system the user is likely using the 64-bit version of Explorer and IE, you'll need 64-bit plug-ins to integrate with those. (you should continue to package and install the 32-bit versions so things will still work if the user finds themselves in a 32-bit file manager or IE instance).
your product would noticeably benefit from increased address space - if your product consumes a lot of data (like database or number crunching apps often do), your application will have far more virtual address space available on a Win64 system and can often use that to advantage.
Note that there may be other good reasons to port, but these are the common ones. Also note that porting for one of the above reasons does not necessarily mean that everything has to be ported. For example, you may be able to get away with just porting your device driver.
If none of these reasons fit, then it might just be your users wanting something for no good reason - educating them may help. But if it starts impacting sales, you might find yourself in a position where you have to port just to make them happy even if there's no good technical reason (hopefully your customers aren't that unreasonable and will listen to sound technical advice).
But even if you don't port your code to Win64 there's no reason not to test and support your application on Win64 systems.
Music software is a bit vague. If you are developing music encoding/decoding software professionally, then 64 bit is something you should take seriously, since it can have noticeable impact on encoding/decoding performance.
Otherwise, while 64 bit is getting increasingly popular, your 32 bit app will still run perfectly so other features are more important in the meantime. However, you should think about 64 bit porting too and refactor your code to be more portable as you go forward.
I would agree with others here that now is a great time to start supporting 64 bit operating systems. With Windows 7 just around the corner you will see a much larger portion of users running with 64 bit operating systems. Even if your software is not 100% optimized for 64 bit processors, the port will gain access to the additional registers and such that are associated with running 64 bit code and could see a performance increase. Not to mention not running up against the 4gb wall and all that.
Just keep in mind your data structures may change in size and your application will likely use more memory.
If I'm wrong about any of this, please, someone correct me!
It's not time to port yet just be sure to also test your software on 64 bit systems. The emulator on Vista or 7 is good enough and should not cause any trouble.
The main advantage is the bigger amount of ram which can be allocated. If there is a lot of ram used and there is a lot of caching going on then you should port.
x64 PC and OS market share will only rise. It's the future. Best to support the future early on.
I am trying to perform a fair comparison of XenServer vs ESX and one comparison I would like to make is performance with multiple VMs. Does anyone know how to go about benchmarking VM performance in a fair way?
On each server I would like to run a fixed number of XP/Vista VMs (for example 8) and have some measure of how quickly each one runs when under load. Ideally I would like some benchmark of the overall system (CPU/Memory/Disk/Network) rather than just one aspect.
It seems to me this is actually a very tricky thing to do and obtain any meaningful results so would be grateful for any suggestions!
I would also be interested to see any existing reports or comparisons that have been published (preferably independent rather than vendor biased!)
As a general answer, VMware (together with other virtualization vendors in the SPEC Virtualization sub-committee) has put together a hypervisor benchmarking suite called VMmark that is available for download. The VMmark website discusses why this benchmark may be useful for comparing hypervisors, including an FAQ and a whitepaper describing the benchmark.
That said, if you are looking for something very specific (e.g., how will it perform under your workload), you may have to roll your own variants of VMmark, especially if you are not trying to do the sorts of things that VMmark benchmarks (e.g., web servers, database servers, file servers, etc.) Nonetheless, the methodology behind its development should be of interest.
Disclaimer: I work for VMware, though not on VMmark.
I don't see why you can't use common benchmarks inside the VMs: WinSAT, Passmark, Futuremark, SiSoftware, etc... Host the VMs over different hosts and see how it goes.
As an aside, benchmarks that don't closely match your intended usage may actually hinder your evaluation. Depending on the importance of getting this right, you may have to build-your-own to make it relevant.
Why do you want to bench?
How about some anecdotal evidence?
I'm going to assume this is a test environment, because you're wanting to benchmark on XP/Vista. Please correct me if I'm wrong.
My current test environment is about 20 VMs with varying OS's (2000/XP/Vista/Vista64/Server 2008/Server 2003) in different configurations on a Dual Quad Core Xeon machine with 8Gb RAM (looking to upgrade to 16Gb soon) and the slowest machines of all are Vista primarily due to heavy disk access (this is even with Windows Defender disabled)
Recommendations
- Hardware RAID. Too painful to run Vista VMs otherwise.
- More RAM.
If you're benchmarking and looking to run Vista VMs, I would suggest putting your focus on benchmarking disk access. If there are going to be performance differences elsewhere I doubt they would be of anything significant.
I recently came across VMware's ESX Performance documentation - http://www.vmware.com/pdf/VI3.5_Performance.pdf. There is quite a bit in there on improving performance and benchmarking.
I manage a database (Oracle 8i) and web server (IIS) for about 50 simultaneous users on average and a theoretical limit of 100 simultaneous users. A mid level system.
We just got a dual-socket Quad-core XEON - 16GB RAM - SAS-RAID-10 beast and I am exploring the possibilities of taking these two separate servers and merging them into two virtual machines both running on the new server (Server 2009 Hyper-V).
1) In general, what are the performance penalties (as well as any gotchas and hidden consequences) of running both the database and web servers as virtual machines on one mega server vs running them on two separate slower boxes? Is it a big NO-NO or it is something worth trying for a mid-level system that will never need to scale?
2) What are the general performance penalties (in percentage) and gotchas for virtualizing just the database server? We run Oracle 8i (but are considering moving to MS SQL Server).
3) If only stress tests can determine an reasonable answer, what would be the easiest way to test these scenarios (tools / configuration).
Thanks in advance for any generous knowledge-sharing.
If you are looking to do this, I would check Microsoft's site and best practices on how to do it. There is a podcast on Deep Fried Bytes that talks about how the Microsoft.com site is setup to use virtual servers and some of their practices on how they implement it. They don't seem to have performance penalties on how they run it, but I am not certain of the details (it also talks about how they use server virtualization like a real organization would and not a company with unlimited amounts of money to throw at a problem).
I believe this is the podcast:
http://deepfriedbytes.com/podcast/episode-8-behind-the-scenes-at-microsoft-com/
With regards to databases, see this question:
Virtualized SQL Server: Why not?
Note that this is specific to sql server, but many of the same principles will apply for oracle.
As for web servers, virtualization is a great idea. It can make it easier to increase reliability and scalability.
I think at your level of concurrent user connections, and the power of the machine, you won't have too many performance issues running SQL Server on a VM.
We have a mix of VMWare ESX VMs and bare-metal OS' running app, web, and DB servers and without a doubt the heaviest loaded DBMS system is on bare-metal machine (Quad proc quad core, etc.). All the little guys, though, live on VMs, and we haven't noticed any problems (even using iSCSI over GigE).
One thing to consider is you won't get any fault tolerance out of a single setup like this because a CPU failure will bring down the entire box, thus blowing up your whole app.
More info on SQL Server HA and Hyper-V, just FYI:
http://blogs.technet.com/andrew/archive/2008/11/10/sql-server-2008-hyper-v-and-high-availability.aspx
Be aware that Oracle has its own guidelines on running in a virtual machine.
The product I work with utilizes Oracle on the back-end, and for heavy use, the overhead of a VM has had negative effects on it.
8i is well past EOL, and was around before virtualization was a Big Thing(tm), so moving to a new edition of Oracle might also be a good plan at the time your migrate to virtualization.
Oracle blog article on 11g in a VM - http://blogs.oracle.com/MingMan/2007/11/oracle_database_11g_successful.html
If you're concerned about timing, also be aware of known clock-drift issues in hypervisors, and available fixes (either from the OS or virtualization vendors).
I recently came across an article dealing with Virtualization Security. I thought it would be worth mentioning here.
The Free MS Windows replacement operating system ReactOS has just released a new version. They have a large and active development team.
Have you tried your software with it yet?
if so what is your recommendation?
Is it time to start investigating it as a serious Windows replacement?
Targeting ReactOS specifically is a bit too narrow IMO -- perhaps a better focus is to target compatibility with WINE. Because ReactOS shares so many of its usermode DLLs with WINE, targeting WINE should result in the app running just fine on ReactOS.
Of course, there will always be things that WINE can't emulate well (hence the need for ReactOS). In this way, it seems that if something runs in WINE, it will run in ReactOS, whereas the fact that something runs in ReactOS doesn't mean that it will necessarily run in WINE.
Targeting WINE is well documented, perhaps easier to test, and by definition, should make your app compatible with ReactOS as a matter of course. In this way, you're not only gathering the rather large user base of current WINE users, but you're future-proofing yourself for whenever anyone wants to use your app with ReactOS.
In their homepage, at the Tour you can see a partial list of office, tools and games that already run OK (or more or less) at ReactOS. If you subscribe to the newsletter, you'll receive info about much more - for instance, I was quite surprised when I read most SQL Server 2000 tools actually work on ReactOS!! Query Analyzer, OSQL and Books Online work fine, Enterprise Manager and Profiler are buggy and the DBMS won't work at all.
At a former workplace (an all MS shop) we investigated seriously into it as a way to reduce our expenditure in licenses whilst keeping our in-house developed apps. Since it couldn't run MSDE fine, we had to abandon the project - hope in the future this will be solved and my ex-coworkers can push it again.
These announcements might as well be also on their homepage - I couldn't find them after 5 mins. of searching, though. Probably the easiest way to know all these compatibility issues is to join the newsletter, or look for its archives.
I have been tracking this OS' progress for quite some time. I believe it has all the potential to really bring an OSS operating system to the masses for it breaks the "chicken and egg" problem: it has applications and drivers from the very beginning (since it aims to have full ABI compatibility with MS Windows).
Just wait for their first beta, I won't be surprised if they surpass Linux in popularity really soon after that...
Post Edit: Found it! Look at section Support Database, it's the web place to go look for whether a particular piece of hardware of some program works on ReactOS.
ReactOS has been under development for a long long time.
They were in some hot water earlier because some of their code appeared to be line by line dissasembly of some NT kernel code, I think they have replaced all of it.
I wouldn't bother with cross platform testing until they hit the same market penetration as Linux, which I would wager is never.
Until ReactOS doesn't randomly crash just sitting there within 5 minutes of booting, I won't worry about testing my code on it. Don't get me wrong, I like ReactOS, but it's just not stable enough for any meaningful testing yet!
No, I do not think it is time to start thinking of it as a Windows replacement.
As the site states, it's still in the Alpha stages. More importantly, whos Windows replacement? Yours? Your users? The former is one thing, the latter is categorically a no-go.
As an aside, I'm not really sure who this OS is targetting. It has to be people who rely on Windows software but don't want to pay, because people who simply don't want Windows can use MacOS / Linux, and the support (community or otherwise) for these choices is good.
Moreover, if you use Linux you already have some amounts of Windows software support via Wine.
Back to people who rely on Windows software but don't want to pay. If they are home users they can just simply pirate it, if they are large business users they already have support contracts and trained people etc. It's hard enough for large businesses to be OK to update to new versions of Windows, let alone an open source replacement.
So I suppose that leaves small businesses who don't want to obtain illegal copies of MS software, can't afford the OS licences and rely on software that only runs on Windows and has bad of non-existent Wine compatibility.
It is a useful replacement for Windows when it runs 'your' software without crashing. At the moment it is not a general purpose os as it is too unstable (being only alpha) but people have used ReactOS successfully in anger for specific tasks already. As a windows replacement it has multiple potential uses, sandbox systems, test and development systems, multiple virtual instances, embedded devices, even packaging/bundling legacy apps with their own compatible o/s. Driver and application compatibility, freed from Microsoft's policy of planned obsolescence and regular GUI renewal, what's not to like?