Citrix is a clusterfuck. It's seriously one of the worst pieces of software ever released. It also doesn't help that companies that use it overload servers and wonder why performance is poor... 100 users on a box with 2GB of ram, single core CPU, each user running 5 apps? Sure, no problem!
by Anonymous Coward writes:
on Wednesday April 04, 2012 @01:18PM (#39573491)
I've used it successfully as far back as 1996 Olympics in Atlanta for BellSouth, & on 32mb Windows NT 3.51 laptops with only a 133mhz single cpu Pentium onboard. Worked like a dream (in combination with Ascend gateways), & we were told "it can't be done" but the DEC boys & myself worked it out. Good team of guys, some are @ MS now iirc.
HERE'S AN EXAMPLE I WORKED ON, PER MY SUBJECT-LINE ABOVE THOUGH & HOW I SOLVED A MAJOR PROBLEM IN CITRIX + CUSTOM VB6 APPS to ORACLE ON SUN MIDRANGES:
I've also coded around it with 100's of users accessing Oracle DB devices on a Sun midrange, coding cross-platform to it from Windows 2000 systems in 1999 using VB6 to a remote campus many miles away over a fractional T1 leased line for a company I worked for then!
The only "hassle" was figuring out that instead of using DoEvents, you use the Sleep API call directly instead to avoid lockups during loops!
I.E.-> Every 6 hrs. or so into the 1st shift's workshift in the factory end (this app worked on the local campus too doing salesforce item lookups & contact mgt. also, not just shopfloor process inventory & tracking), it was locking up the single shared session when populating data display grids!
The use of Sleep Win32 API calls solved it (oddly too, because sleep is used in DoEvents calls).
Took down CPU usage from 100% lockup, down to 1% per client workstation.
The problem? Middleware drivers - they're NOT built to 'timeslice' and during single shared sessions to multiple remote campus users?? It caused that problem (we used a combination of ADO (MS db driver, faster on reads to Oracle) & OO40 (Oracle db driver, faster on writes back to Oracle on SUN system)).
* It's ALL how you code for it, to avoid the hassles you speak of...
APK
P.S.=> It is still running that companies systems (ableit much faster, since it was using Pentium II 350mhz CPU systems with 64mb RAM on them in 1999, & now uses Intel Core I7 920 machines with 2gb of RAM on them).
Done right, where it should be done, IN THE CODE OF THE APP ITSELF!
(Without having to use the "rig jobs" in the registry that Citrix &/or TS offer for "bad boy apps" (that eat too much CPU per shared session like I noted above - I call that "putting a bandaid over a bulletwound" & BAD DESIGN trying to force the OS to offset that which SHOULD BE DONE IN THE APPLICATION CODE ITSELF))... apk
Ugh, Citrix... (Score:1, Informative)
Citrix is a clusterfuck. It's seriously one of the worst pieces of software ever released. It also doesn't help that companies that use it overload servers and wonder why performance is poor... 100 users on a box with 2GB of ram, single core CPU, each user running 5 apps? Sure, no problem!
Depends HOW you code apps on it... apk (Score:0)
I've used it successfully as far back as 1996 Olympics in Atlanta for BellSouth, & on 32mb Windows NT 3.51 laptops with only a 133mhz single cpu Pentium onboard. Worked like a dream (in combination with Ascend gateways), & we were told "it can't be done" but the DEC boys & myself worked it out. Good team of guys, some are @ MS now iirc.
HERE'S AN EXAMPLE I WORKED ON, PER MY SUBJECT-LINE ABOVE THOUGH & HOW I SOLVED A MAJOR PROBLEM IN CITRIX + CUSTOM VB6 APPS to ORACLE ON SUN MIDRANGES:
I've also coded around it with 100's of users accessing Oracle DB devices on a Sun midrange, coding cross-platform to it from Windows 2000 systems in 1999 using VB6 to a remote campus many miles away over a fractional T1 leased line for a company I worked for then!
The only "hassle" was figuring out that instead of using DoEvents, you use the Sleep API call directly instead to avoid lockups during loops!
I.E.-> Every 6 hrs. or so into the 1st shift's workshift in the factory end (this app worked on the local campus too doing salesforce item lookups & contact mgt. also, not just shopfloor process inventory & tracking), it was locking up the single shared session when populating data display grids!
The use of Sleep Win32 API calls solved it (oddly too, because sleep is used in DoEvents calls).
Took down CPU usage from 100% lockup, down to 1% per client workstation.
The problem? Middleware drivers - they're NOT built to 'timeslice' and during single shared sessions to multiple remote campus users?? It caused that problem (we used a combination of ADO (MS db driver, faster on reads to Oracle) & OO40 (Oracle db driver, faster on writes back to Oracle on SUN system)).
* It's ALL how you code for it, to avoid the hassles you speak of...
APK
P.S.=> It is still running that companies systems (ableit much faster, since it was using Pentium II 350mhz CPU systems with 64mb RAM on them in 1999, & now uses Intel Core I7 920 machines with 2gb of RAM on them).
Done right, where it should be done, IN THE CODE OF THE APP ITSELF!
(Without having to use the "rig jobs" in the registry that Citrix &/or TS offer for "bad boy apps" (that eat too much CPU per shared session like I noted above - I call that "putting a bandaid over a bulletwound" & BAD DESIGN trying to force the OS to offset that which SHOULD BE DONE IN THE APPLICATION CODE ITSELF))... apk