Ok, first off nothing in this post is official for what/how you can use a license. That is all set in the legal wording of our license agreement. I think this all is in line with that but I’m not a lawyer and so I may have something wrong.
Second, pricing against use is fundamentally our allocating our R&D costs, etc. across our customers. What we have always aimed for is to keep it simple. There are always more complex measuring systems that might be slightly “fairer”, but the added complexity would be such a PITA that it’s not worth it.
We now limit each license by the number of cores & threads. The limit is the same in a license, if you have a 4 core license it is also a 4 thread license. Using the example of a 4/4 core/thread license it works as follows:
- If the server has 4 or fewer cores, you can have as many threads, across as many JVMs/CLRs on that machine if you wish. The thread limit is ignored.
If the server has more than 4 cores, you can only have a maximum of 4 threads generating reports. This limit is across all JVMs/CLRs on the system.
- The count starts when you call Report.ProcessSetup()/ProcessReport.processSetup() on the report object. The count ends when Report.ProcessComplete()/ProcessReport.processComplete() returns.
- If you try to run a 5th report in this case, Windward will throw an exception (which you can catch). Because of race conditions, when this occurs the count of allowed threads may drop to 3 until you bounce your system. So don’t run more threads than allowed.
So what does this mean for you?
If your server is spending a large part of its processing time generating reports, then get a license that is for the number of cores on your box. And create twice as many threads as cores for maximum throughput. This remains the best approach for heavy duty report generation.
If your report throughput is minimal and you have full control over the number of threads, go with the thread limit. This is useful for an application that runs on a 64 core server and generates 3 – 4 reports/day. Generate them sequentially and you will have no issues.
With a web app (and other use cases) you have no control over the number of threads. Many web servers will create a thread for each session and you don’t want to refuse any sessions over your report limit – even if the web app is doing nothing but report generation. But we have two solutions here.
- Traffic cop approach. Keep your own count of the number of thread requests in process. If 4 are in process then on the 5th put your thread into a wait state on a semaphore. When any report completes, decrement the counter and signal the semaphore. The suspended thread will then resume and generate its report. We will provide sample code (Java & .net) for this soon.
- Throw to Javelin approach. Call our Javelin server with each report request and it will return the generated report.”You place Javelin on a server of your own where that server has the number of cores matching the Javelin license (so it can have unlimited threads).”
- Maybe we can… There is one other approach we are considering. We charge per report (and per page) against a server running on your system. But for each report it connects to our billing server so we can track reports run on our server. This approach will require a network communication for each report, but the communication will be one small message round trip so it should be fast.
And when we have 64,000 core servers
It’s coming. Moore’s Law is still in effect, but the win is now additional cores, not faster speed. I’ve sketched out how to break out report generation so it can use multiple threads to generate a single report. For all except applying the datasource the way we can break it out allows us to use a large number of threads (basically one per paragraph). And for the datasource, it is dependent on the selects in the tags but for most use we can have a thread per forEach iteration.
What does this mean? It means that running on a 64 core system a single report will be generated about 50 times faster. That means where before a 350 page report would take 50 seconds to be generated, it would now be 1 second. (note: If you need to generate 128 reports at the same time, then you won’t see this speed improvement – the win here comes when there are more cores than simultaneous report requests.)
But… How on earth do we price the licenses when we have this functionality?