Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/26/18 in all areas

  1. Tutorial https://www.inflectra.com/support/knowledgebase/kb306.aspx BR Adan
    1 point
  2. Try to reduce your exe to below 16m by not include debug information or config your IIS to allow upload files greater than 16m
    1 point
  3. Maybe I misunderstood, but why such difficulties? Why not?: procedure TMainForm.Btn1Click(Sender: TObject); begin ShowPsw:=not ShowPsw; if ShowPsw then UniEdit1.PasswordChar:=#0 else UniEdit1.PasswordChar:='*'; end;
    1 point
  4. Hi We deployed a large Microsoft Sharepoint enviromnent for one of our corporate customers. The setup we did was able to handle 30000+ connections and ran on VMWare hosts. I would follow the same approach as Sharepoint is based on .NET which is even more resource intensive that Delphi/UniGUI/mormot. What we did was to have 3 web frontends. Between these three frontends we had Microsoft NLB enabled. (You could look at a F5, but the cost is enourmous.) These frontends then connected to the rest of the sharepoint farm components. Also note that the database setup was key to the whole solution. The database itself ran on a MSSQL failover cluster. The hardware we had for that was 16 cores with 128GB RAM with enterpise storage connected. The solution was able to handle the connecting clients easily. If you plan to do reporting, I would advise having a seperate reporting server. If you plan to have specific jobs that must run at specific times, I would suggest having a seperate server for that as well. So my advise would be: 1. Make sure that the NLB between the UNIGUI frontends are setup correctly, especially if you are going to use virtual machines as front ends. VMWare for example needs extra configuration to be able to do NLB. 2. Make sure that the database server have enough resources. No delays should be on the storage side. Also keep in mind that constant database maintenance must be done to keep it optimized. You will therefor need a good DBA. 3. Reporting must be done on a seperate server 4. Scheduled or other tasks must also be done on a seperatele server. 5. Database backups must be done whenever the expected connections will be at it's lowest 6. If you need to do database synchronization between database/sites, you might consider using MSSQL or Oracle. 7. If you plan to run on the internet, I would suggest putting the frontends in a DMZ. I would also suggest using a reverse proxy solution to bump up security. I hope this will help a bit, as I have had great success with this type of architecture. Regards Stiaan
    1 point
×
×
  • Create New...