RTC Forums
November 24, 2024, 08:37:35 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: App to create and distribute PDF's  (Read 6936 times)
classic12
Guest
« on: November 09, 2012, 05:17:03 PM »

I have gone through the tutorials and have a client server working.
I need to do the following.

From a web application or a mobile app using a http request I would send some information eg CustNum=20&Amount=40.33 etc etc

Once I get the data I will be using inserting / updating a Mysql database with the data.
I then use Quckreports to produce an Inv.
Save as a PDF.
Upload the PDF to our webserver.

I would then be duplicating the process for Purchase orders / correspondence etc.

I am presuming the approach I need is an expansion of lesson2.
ie a different dataprovider for each type of request (Inv , Purchase order)

What I am not sure of is:

1. How many requests can be handled at once (how long is a piece of string)
2. Is each request in its own thread ie if we get 10 inv requests & 10 Purchase order requests will they all queue and process as expected.
3. Is there any benefit in having a different server (on a different port) for each request

Cheers

SteveW


Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #1 on: November 09, 2012, 05:32:44 PM »

1. Provided you have set the "MultiThreaded" property on the TRtcHttpServer component to TRUE, the  number of requests which the Server can handle at the same time will be limited by the number of Threads available in the RTC Thread Pool (and things like available Memory, CPU, Database connectivity, etc). The default RTC Thread Pool size is 64, which should be enough for most Applications. If you need to handle more long-running requests parallel, take a look at global variables in the "rtcThrPool" unit.

2. RTC components with "MultiThreaded=True" will use the RTC Thread Pool, which takes care of evenly spreading requests across all available threads. So yes, if you get 10 requests at the same time, they will all be processed in parallel if you set the "MultiThreaded" property of the TRtcHttpServer component to TRUE. You just need to make sure that the code you write inside RTC events is thread-safe.

3. No. The opposite is true. It is best to have a single Server per PC. Using multiple Servers on a single PC would only cause problems. When your load starts exceeding limits of a single PC, you should start thinking about using a Server farm (multiple PCs, one Server on each, connected together with a Load Balancer).

Best Regards,
Danijel Tkalcec
Logged
Ronald van Tour
RTC License++
*****
Posts: 37


« Reply #2 on: November 10, 2012, 08:22:26 PM »

" 3. Using multiple Servers on a single PC would only cause problems

I wonder what kind of problems ? I have 5 RTC server programs running on 1 PC but it is a very stable situation.
 
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #3 on: November 10, 2012, 08:46:43 PM »

The problem is balancing requirements of each Server when you take available resources into account (like Memory, CPU, Threads and Bandwidth).

When you have a single Server running on a PC, that Server will have all the resources to itself. While things like CPU usage and file access aren't critical, some resources are limited by your hardware (like Memory and maximum Thread count). If you have multiple Servers running on the same PC, all of these Servers will have to share available resources among each other. With 5 Servers running on the same PC, you need to dedicate a specific amount of your resources to each one of your Servers. Even if you do that correctly, so that all of your Servers can run without grabbing too much for themselves, chances are high that you will end up using only a fraction of your resources, no matter now high the current load on your Servers is.

Let's say you have 1 Server which has access to all your resources. Even if you are hosting 10 different applications on that single Server, because the Server has access to all the resources, it will easily scale to use maximum of your available resources. But if you have 5 Servers, each hosting 2 applications, you will need to define at least RAM and Thread limits. And unless all of your Servers will always be under equal load, most of your available resources will remain unused.

One Server per PC simply means better utilization of available resources, without worrying about possible requirements of other Servers running on the same PC.

Best Regards,
Danijel Tkalcec
Logged
classic12
Guest
« Reply #4 on: November 13, 2012, 08:36:27 PM »

I will have the following processes in my app.
1. I get the http request and use a MySQL database and query components to update / insert any records.
2. I use a quick report component to produce and save the file on the server.
3. FTP the file to a web server using your FTP component.

Are all the above thread safe out of the box. Ie if I am using various instances of these is it all handled by your components ?

Cheers

Stevew
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #5 on: November 13, 2012, 09:08:18 PM »

The RTC SDK doesn't have anything to do with 3rd-party components you use. It is your own responsibility to handle that. But, generally speaking, if 3rd-party components are designed to work from background threads and you make sure that you will be using a separate instance for each component per request, then your code will most likely be thread-safe.

Best Regards,
Danijel Tkalcec
Logged
classic12
Guest
« Reply #6 on: November 13, 2012, 09:39:27 PM »

Can you expand on :
make sure that you will be using a separate instance for each component per request.

Lets say I have 2 dataprovider to do the following.
1.(Invoice Creation) This is called when the Http request contains Invoice. 
2.(Purchase Creation) This is called when the Http request contains Purchase. 

So for 1. I need to have a separate MYSQL Database Connector & MYSQL query and a separate Quickreport component.

So for 2. I need to have a separate MYSQL Database Connector & MYSQL query and a separate Quickreport component.

Is this assumption correct ?

Cheers

SteveW
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #7 on: November 13, 2012, 10:06:51 PM »

No, that is NOT correct.

If you set the MultiThreaded property of the TRtcHttpServer component to TRUE, then each Thread (not RTC component, but a running thread) will require a separate instance of a 3rd-party component, unless that speciflc component is designed to be used from multiple threads at the same time. If there are 100 clients requesting stuff from the Server at the same time and you have set the Server up to use 100 threads (default thread pool size is 64), then you will need 100 instances of all the 3rd-party cmponents you are using for processing these client requests. The number of RTC components does NOT play a role in this. Only the number of threads that you want the Server to use at the same time for processing your requests.

On the other hand, if you set the MultiThreaded property on the TRtcHttpServer component to FALSE, then all the requests will be processed from the Main thread and you will need only one instance of each 3rd-party component to handle your requests, since there will be no paralel code execution happening.

The easiest solution to making your multi-threaded application thread-safe, is to create all the 3rd-party components when you need them (for example, after you have received the request and know what you have to do) and destroy them when you no longer need them (for example, after you have processed the request and have a response ready). A better and a bit more compex solution is to use pools of reusable objects, so you don't create and destroy the same objects over-and-over-again, but implement a pool which will dinamically create objects if the pool is empty, or take an object from the pool (extract it, so other threads can't get the same object). When you no longer need the object, you can either return the object back to the pool (the usual behavior), or destroy it (in case it is no longer valid, or damaged in some way).

Best Regards,
Danijel Tkalcec
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.029 seconds with 17 queries.