I was wondering if anyone had some good general information on windows terminal services and how it works.
I'm wondering:
If a DLL is loaded into memory is it available for all users or reloaded for each user. (or does it depend on something else)
A specification for an example server and how many concurrent users it supports with general use....
Any issues with them, I used one a while ago and we had sporadic freezes for a few seconds every so often. This could not be tracked down to a network issue someone suggested something to do with remote printers being attached to the system. It really annoyed users seemed to happen often when going to the start menu.
Is 2008 a big upgrade in terms of performance to 2003
Terminal Services is simply like a server with multiple "remote desktop".
DLL is not shared between sessions, just like ordinal process.
You need a special license if you want to use standard Windows server
I suggest removing all the printers when you want to use it (you can also disable them in client side), but that's not a big issue
2008 is far better for performance and security, but you'd also need more recent RDP clients.
Related
We want to start working with liferay. But the server is too heavy and the developpers computer don't have enought RAM. We want to centralize the server instance.
In other words, we want to build a development server where all developpers can connect and directly develop in their web browser, compile, view the result and push the code to git repository.
I found some good cloud IDE like eclipse CHE and a good maven archetype for liferay projet. So i can build the projet with maven. But now i want to know if it is possible to configure Liferay like every developpers can work without troubling another. And if possible, How ?
The developpers can share the same database and can use different port. Maybe, the server can generate tempory URL like some online cloud editor.
I found this post Liferay With Multiple Server Instances, but i don't think is the best way because he create one server per project. I think is too heavy.
If necessary, We have kubernetes in our IS.
Liferay's tomcat bundle, by default, is configured to take a maximum of 2.5G for the process, but it can run with far less - the default only recently was bumped up, because many people never change the default and then wonder why production systems run out of memory. For 1 concurrent user (the sole developer) on a machine, I guess that the previous default of 1G heap space is enough. Are you saying that that's too much for your developers' machines?
Having many developers on a shared server poses one problem: Yes, you may deploy different code from different machines, but: How about setting a breakpoint? Can you connect with multiple debuggers? If something fails, how do you know whos recent deployment caused the failure?
Sharing a server is an integration technique, not a development technique. If your developers don't have enough memory available for running their own Liferay server next to their IDE, it's a lot cheaper to upgrade their machines than to slow them down when everybody is accessing the same server and they can't properly debug. You pay the memory once, but your waiting developers by the hour.
Is it possible to share one server? Sure it is.
Is it possible to share one server without troubling each other? I doubt.
When you say: You think it's too heavy: What are you basing that assumption on? What does the actual developer machine look like and what keeps you from investing in the extra memory?
It's trivial to share some infrastructure - i.e. have all of them connect to the same database server (and give everyone their own schema). But just the extra effort and setup might require you to pay the developers by the hour as much as you'd otherwise pay for a couple of memory chips.
And yet another option is: Run Liferay on a remote server, but keep 1 instance per developer. This way you don't need the local memory, but can have the memory in the cloud. Calculate if you pay more for remote cloud machines than for local memory - that decision is up to you.
I heard that minecraft server is very leaky, can consume a lot of resources very quickly. People say to use a virtual machine, all well and good. I'm making an application to automate server setup, and I'd like my whole application (including minecraft) to run in an ultra basic auto setup vm (or something similar). I've heard of mineos, but I'm not sure if that can be set up very quickly. The vm will be so basic it won't even have a ui. I'm using a Mac, not planning to distribute the server WITH the application but have it download from the minecraft server, not modified.
I want it to be like a one-click-done solution for the end user, they don't have to worry about minecraft server gobbling up resources because it's be in a controllable virtual machine.
Distrubuting minecraft server (Notch's property) could be an issue, but if anyone knows about that if be happy to hear.
If you intend for a server to be fully configured and only for your user to only have to download and 'open' it, what you're seeking is known as an 'appliance'. Virtualbox supports the open-standard of such appliances, allowing a single file to be distributed and it contains all the virtualized hardware info as well as the OS/filesystem. A number of other formats exist, such as Turnkey.
In all likelihood, I would find MineOS CRUX to be perfectly suited for this sort of one-click-done, since the OS was designed for pretty much exactly what you're trying to do...only without the configure-the-hardware-for-the-user (it uses an ISO and an installer, the process you would automate for the end-user).
That said, this distribution has never at any point packaged Minecraft files, as clearly stated: "this Linux distro does not contain ANY Minecraft files. The scripts are, however, designed to download/update files directly from the source: http://minecraft.net"
Hope this answers all the concerns, despite being an old thread.
I'm looking for a way to allow potential customers to try my application before they buy it.
The product is a windows forms application that requires an SQL Server database to operate.
Although I have a functional demo that the customer can install on their network, I want to make it easier for them by have them "play" with it at my environment.
I remember Microsoft had (has?) something similar. I was testing Visual Studio a few years ago in a virtual environment where I was connecting to a server at Microsoft.
They setup the environment this way so when a user logs off after using it rollback his actions. Or to explain it better: when a user logins it starts with a new, clean environment.
So any projects I've created testing Visual Studio were lost after I logged off.
Any suggestions?
Thanks.
Some solutions that come to mind:
Provide remote access
You could provide access to a running instance of your application via some sort of remote connection protocol, e.g. via RDP or via VNC.
For example, there is a Java VNC client which can run as a Java applet; you could put that on a webpage and have it connect to a VNC session you host on your servers.
Or use Windows Terminal Server, and allow connection via RDP.
Both solutions of course have the drawback that people need to open the appropriate ports, if they are behind a firewall. There might be ways around that, however (e.g. you can run VNC over HTTP).
VM image
A completely different solution: Provide a ready-to-run VM image (for VMWare, VirtualBox or similar) of your application, including server and everything. You would need a demo version of your app though, plus getting redistribution rights for all the proprietary components (Windows OS, SQL server) might get hairy.
Offer videos
Often people do not really need to actually use the app; they are mainly interested to see how it works. So maybe it is enough to host videos of the app in operation. That allows you to put in some advertising for your features, and lets you show the users what they might miss when testing on their own.
I am trying to get a better idea on this as so far I have had mixed answers in person.
I am a solo dev in a 5 man IT dept for a Health Care related business. My developer machine is running Win 7 RC1 (x64) but my users are all running Win XP Pro (x86). Is this a big deal? Whan kind of pitfalls should I be aware of? Is having a VM of the user image enough?
Should my environment completely mirror my end user's?
Your development environment doesn't need to mirror your user's environment, but your testing environment certainly should!
Having a VM of the users image for testing would probably be good enough.
First and foremost, as a developer, your machine will never look like your client's machine. Just accept that.
You will have tools and utilities installed that they won't have. That will fundamentally change the configuration of your machine from the outset. You have DLLs, applications, services, and possibly drivers installed that your users have never even heard of (and likely never will).
As far as the OS is concerned, Win7 and WinXP, despite claims to the contrary, are not the same animal. Don't believe the hype. Having said that, don't believe the anti-hype, either. Just be aware, as you well should, that any piece of software developed under one version of an OS is not guaranteed to behave the same way under another.
The short of it: Yes, it's important that your environment is different. Should you panic about it? No. Should you account for it in testing? Absolutely. As rigorously as possible.
Is this a big deal?
Yes, it is. You have an OS 2 generations ahead of the one the users have, including you are running a non-release version.
Whan kind of pitfalls should I be aware of?
Depends on what you are developing. Some libraries may be missing that you already have, then the versions may be different etc.
Should my environment completely mirror my end user's?
Not necessarily, but you definitely need to have a testing environment that corresponds to the one the users have.
If you were developing web applications, all that would not have been an issue (well, unless you used some fancy fonts that are not present in a clean OS by default).
Its unreasonable to develop on exactly the same type of system as your users. If nothing else, your life is made much easier by installing all sorts of developer tools your end users have no reason to install. I hear Visual Studio in particular likes to squirrel a number of potential dependencies onto a system.
However, you do need to test on a system more inline with that of your end users. If you have access to an image of such a system, your VM approach should be sufficient. If nothing else, you should try for a staged (or better yet, beta/trial) release so as to avoid pushing a completely broken app out the door.
In short, don't fret about the development environment but put some thought into your testing one!
It's effectively impossible for any two machines to be set up the same, so development and production environments will always be different. One advantage in them being VERY different is that you will be more aware of possible deployment problems.
The type of environment that you need to use for testing entirely depends on what you're developing.
If you're writing web applications, having a VM with the user's standard image should be more than enough (just make sure the VM contains all the browsers your users might be using). Web development is much easier in this respect (I'm also running Windows 7 and have a couple VMs to test various environments)
If you're writing a full desktop environment, you'll probably want to ask for a second computer that you can test on (even if just to test before a final release). I say that because of differences in hardware. Just imagine if something runs fine for you, but slows down the users computer so that everything else is unusable. Opposite of that, you might spend hours trying to make something faster in the VM whereas running that on a users computer might run just fine.
Simplified, I have an application where data is intended to flow over the internet between two servers. Ideally, I'd like to test at what point the software ceases to function. At what lowerbound limit (bandwidth, latency, dropped packets) do things stop working to test the reliability of the software.
What I thought I would do was the following:
Setup up 3 machines (VMware instances)
Install the 2 applications on two of the servers.
Setup up the 3rd server to sit between the two machines by doing some sort of magic with Routing and Remote Access on Windows 2003
Install either Traffic Shaper XP or NetLimiter to limit the bandwidth
Run something like TMnetSim Network Simulator to simulate a bad connection.
Does this sound like a good idea or are there easier/better ways of doing this? I'm not that comfortable on Linux and my team mates are even less so.
WANem does exactly this. We have used it both in a virtual machine on the desktop and on a dedicated old pc and it worked great. It can simulate all sorts of broken connectivity.
FreeBSDs ipfw has provisions to simulate links with a given bandwith, latency or error rate. You could use that FreeBSD machine as your machine "in the middle" in your above setup.
You probably can also run at least one of the endpoints on the same machine if you want to reduce the amount of servers involved.
Someone actually packaged up the settings and whatnot necessary for the FreeBSD solution to this problem and they call it DUMMYNET.
It simulates/enforces queue and bandwidth limitations, delays, packet losses, and multipath effects. It also implements a variant of Weighted Fair Queueing called WF2Q+. It can be used on user's workstations, or on FreeBSD machines acting as routers or bridges.
It can simulate exactly what you want, and its free and will boot onto commodity hardware. They even have a canned install of it that is small enough to put on a floppy disk (!) that you can download at that link.
Maybe it is time to learn a bit about Linux because adding a 50ms delay on every outgoing packet can be done in typing just one line:
tc qdisc add dev eth0 root netem delay 50ms
For more see the Linux Traffic Control HOWTO
We had a similar requirement some ten years ago - I'll see if I can recall how we managed it.
If I remember, we wrote a socket proxy program which was controlled by inetd on a UNIX box. This socket would accept connections from a client and open equivalent sessions through to the server. It would then loop, passing messages in both directions.
The way we achieved WAN characteristics was to introduce random delays (with upper and lower limits) in both the connection establishment and the passing of data once the link was up.
It also had the feature to drop the link occasionally as WAN links were less reliable for us than local traffic.
I recall we had to make it threaded to stop the delays from affecting reverse traffic on the link.
There is a very good (and free) Microsoft solution for that, we use it for quite some time and it works great, it can very easily simulate every thing(packet loss, low bandwidth, disconnection, latency....)
This is the best solution i found for a windows environment
More information and a download link can be found here: MARCO blog post
this product has gone some evolution and it is now integrated into visual studio as part of the automation testing, but i found the use of the standalone(that is quite hard to find, so keep a local copy) to work much better. keep in mind that you need at least two computers(or VMs) since you need to pass through a network adapter in order for the application to work its magic.