"GlenB" wrote:
> No problem. I have never really load tested FC to the point of
saturation,
>because I've never really been able to purposely hit it. I have quite a
few
>pool licenses sitting in the background and at the most I've seen 18
>concourrent licenses being used. Our search engine is quick, but some
vague
>searches could take 2-3 seconds to respond with a thousand part numbers.
>That ****fts quick hits over to other slots. Coyote is a tame beast and
it's
>quite compact. I'd recommend it just for the sake of features and age,
over
>FC. Doug's put a lot more time in its development versus FC. FC was
steered
>towards their Java services not long after it became solid, so I think
the
>raw web feature set was left up to the developer to fulfill. As I stated
>before, the HTTP POST content type limitation is a bit of a headache if
you
>plan on using it for anything other than traditional web pages.
Misc notes:
Glen, I think there are only a couple people who know/care about the
difference between GET and POST, a tiny subset of them use D3/FC, and
we can probably count on a finger or two how many would care about
specific content-type issues. If RD had more clients who made an
issue about this then you might get a product change but I'm afraid
you're in the minority. If I were you I'd impress upon RD the gravity
of your situation: You've been using FC for years but you're on the
verge of looking for new solutions (and new ways to spend your money),
in part because they haven't made this oh-so-simple change that a lot
of people could actually use. (Allowing POST of raw XML data like it
comes via web services, rather than only through a browser Form action
POST.) Don't take this through Sup****t, it's a business issue for
Sales management.
I have a client using FC as a pure data pipe. It processes massive
volumes of transactions per day and the client is confident enough to
double that with new business. (Yes, I need to quantify that - no
time or need.) FC had stability issues early on but I haven't seen
any issues since about v3.3. They introduced some fine-tuning
capabilities that allow the site admin to configure timeouts and how
errors are handled. These were very helpful.
Ironically, and I'm sure some would disagree, FC is one of those
products that's reached a level of stability where it doesn't fall
over without some outside influence, so there's nothing to complain
about, so we don't see it mentioned in forums anymore, so there's
hardly any new interest, so it's sort of faded into the sunset. I'm
not saying lack of popularity is due to unquestionable success, more
like it's a shame that RD has no marketing department to get people to
use the software that they finally get working right.
All that said, personally I think it's not tough to DoS an FC site, so
IMHO it's an interface for intranet/extranet, or low-profile internet.
YMMV For the right price I'll be happy to attempt to crash anyone's
server. ;) And having said that - it's also easy with FC to
recognize a DoS attack and cu****on against it. To date however, I
haven't had a single site that sees a need for this sort of hardening.
The only sort of protections I've written into FC code were things
like making sure that session IDs were coming from the same system to
which they were issued, verifying legitimate browsers, and other basic
authentications - yes, all possible with FC and BASIC.
About Java, it's really a shame that by the time RD finally came out
with a Java pipe, hardly anyone in this market seemed interested in
Java anymore. People give me grief about adopting .NET but no one
asks for Java development, and requests for anything else like PHP are
a just a tiny trickle.
Oops, almost 2am, time to get back to work...
T
|
