rejetto forum

Is HFS Reliable for Use In Office?

chirag · 5 · 5477

0 Members and 2 Guests are viewing this topic.

Offline chirag

  • Occasional poster
  • *
    • Posts: 2
    • View Profile
Hello Everyone
HFS is a wonderful program for personal use. However i am interested to know if it can be deployed in office scenario.Is the software reliable when it comes to handling large data traffic?How many concurrent users can it handle max?Here are some typical scenarios that i will face with HFS in Office-

Scenario-1 (through internet)
----------

Total 100 Password protected Accounts
25 Users Uploading Data*, any given time (* Each File is max 10MB since we are only dealing with MS office files)
50 Users downloading their data for viewing any given time
25 Users, logged in but idle

Scenario-2 (through internet)
----------
Total 50 Password protected Accounts
40 Users Uploading Data, all simultaneously .
10 Downloading data

Scenario-3 (through LAN)
----------
Total 75 Users
25 Users Uploading Data, at any given time. (each file size is  1GB)
15 Users downloading data
Rest, logged in and idle.

Will HFS able to handle these scenarios? and in-general, can i use it in my office?


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13523
    • View Profile
welcome chirag!
i think your scenarios are probably ok.
You may face difficulties uploading the 1GB files.
there's no license problem with the office.
i can't say the performance you can expect, but of course they depends heavily on your hardware and bandwidth.
HFS 2 is not an high-performance software anyway, and i suggest to go for a test before you depend on it.
I suggest you to go directly on version 2.3, even if it's still declared beta.

HFS 3 is expected to be high-performance but it is in an early stage at the moment, and will take at least a year to be developed.


Offline chirag

  • Occasional poster
  • *
    • Posts: 2
    • View Profile
Thank you very much rejetto for pointing me in the right direction.
As you have said, it would be great to test the software before deploying it but the problem is i run an Managed Service business planning to provide private file servers to our small business clients.This makes it quite impossible for me to "test" the solution since each environment is different.However the "Scenario 1" is what we are expecting to face with most of our clients.
As for the hardware and bandwidth-

HFS will run in a Virtual Machine (VMWare Workstation 8) with Win7 x64, 1.5GB of RAM and 40 GB* HDD (*expandable)
We expect to run atleast 10 VM's in the host system with the following specs-
Intel i7
32GB RAM
1TB HDD
Win 7 x64
4MBps Internet Connection
The host system will restart only once everyday
The client will access the file server through Internet mainly

Will this be sufficient to handle atleast Scenario-1 ?
I will be using HFS 2.3 and DYNDNS (since i dont have a static IP)

What we want out of HFS is-
It Should Not Hang or stop responding with Scenario-1 type usage
Slow upload or download speeds are very acceptable but non-responsiveness of the software-No way

Also i wanted to know if there is any "Upload Client" for uploading files directly from an users desktop to the web server
 (like windows live mesh)

Looking forward for an helpful reply
Thank You


Offline crazyboris

  • Tireless poster
  • ****
    • Posts: 140
    • View Profile
i would use more RAM.
windows itself needs almost 1.5 gig RAM.
atleast add 2-3 gig and you will get a more stabe and faster "webserver".
if you only have 1.5 gig use windows xp instead , as it only needs about 350mb RAM


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13523
    • View Profile
to be honest HFS was not designed to be an always-on service, but for a very different use case.
Many users use it this way, but i know very little of their traffic and some occasional problems happened.
I personally cannot say you anything more. Maybe someone else will.

i'm designing version 3 to be much more solid from the ground up. But don't wait for it.